From b982973f37cfd56c20fe0a398c2162ee9191ff95 Mon Sep 17 00:00:00 2001 From: Matthew Gaughan Date: Mon, 6 Oct 2025 09:37:06 -0700 Subject: [PATCH] updating human sampling --- dsl/100625_human_info_sample.csv | 110048 ++++++++++++++-------------- dsl/human_sampling.R | 7 +- 2 files changed, 55688 insertions(+), 54367 deletions(-) diff --git a/dsl/100625_human_info_sample.csv b/dsl/100625_human_info_sample.csv index 980c43e..7b9534d 100644 --- a/dsl/100625_human_info_sample.csv +++ b/dsl/100625_human_info_sample.csv @@ -1,16924 +1,19914 @@ "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" -37,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","For example, you can't copy/paste in the edit summary box. +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. --------------------------- -**Version**: unspecified -**Severity**: major",1379680980,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_description","VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed./n/nFor example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major","VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed./n/nFor example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major","Unbreak Now!",100,1379977964,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed.', ""For example, you can't copy/paste in the edit summary box."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed." -37,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","For example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major",1379680980,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_description","VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed./n/nFor example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major","VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed./n/nFor example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major","Unbreak Now!",100,1379977964,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed.', ""For example, you can't copy/paste in the edit summary box."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: major" -37,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","For example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major",1379680980,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_description","VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed./n/nFor example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major","VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed./n/nFor example, you can't copy/paste in the edit summary box. - --------------------------- -**Version**: unspecified -**Severity**: major","Unbreak Now!",100,1379977964,NA,"resolved","True","c1",3,"True","False",11,NA,"['VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed.', ""For example, you can't copy/paste in the edit summary box."", '--------------------------\n**Version**: unspecified\n**Severity**: major']",TRUE,0,"For example, you can't copy/paste in the edit summary box." -38,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85784 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85784",1379977939,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Change 85784 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85784","Change 85784 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['Change 85784 merged by jenkins-bot:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL']",NA,0,"Change 85784 merged by jenkins-bot:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL" -39,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85783 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85783",1379977741,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Change 85783 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85783","Change 85783 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['Change 85783 merged by jenkins-bot:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL']",NA,0,"Change 85783 merged by jenkins-bot:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL" -40,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85784 had a related patch set uploaded by Catrope: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85784",1379977609,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Change 85784 had a related patch set uploaded by Catrope: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85784","Change 85784 had a related patch set uploaded by Catrope: -Only listen for copy/paste on documentNode and pasteTarget - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['Change 85784 had a related patch set uploaded by Catrope:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL']",NA,0,"Change 85784 had a related patch set uploaded by Catrope:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL" -41,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85783 had a related patch set uploaded by Catrope: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85783",1379977566,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Change 85783 had a related patch set uploaded by Catrope: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85783","Change 85783 had a related patch set uploaded by Catrope: -Only listen for copy/paste on documentNode and pasteTarget - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['Change 85783 had a related patch set uploaded by Catrope:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL']",NA,0,"Change 85783 had a related patch set uploaded by Catrope:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL" -42,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85204 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85204",1379702067,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Change 85204 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85204","Change 85204 merged by jenkins-bot: -Only listen for copy/paste on documentNode and pasteTarget - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Change 85204 merged by jenkins-bot:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL']",NA,0,"Change 85204 merged by jenkins-bot:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL" -43,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85204 had a related patch set uploaded by Esanders: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85204",1379684992,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Change 85204 had a related patch set uploaded by Esanders: -Only listen for copy/paste on documentNode and pasteTarget - -https://gerrit.wikimedia.org/r/85204","Change 85204 had a related patch set uploaded by Esanders: -Only listen for copy/paste on documentNode and pasteTarget - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Change 85204 had a related patch set uploaded by Esanders:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL']",NA,0,"Change 85204 had a related patch set uploaded by Esanders:\nOnly listen for copy/paste on documentNode and pasteTarget\n\nGERRIT_URL" -44,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Marking as a regression as this is new behaviour in the latest release (version ""false"")",1379683942,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Marking as a regression as this is new behaviour in the latest release (version ""false"")","Marking as a regression as this is new behaviour in the latest release (version ""false"")",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Marking as a regression as this is new behaviour in the latest release (version ""false"")']",NA,0,"Marking as a regression as this is new behaviour in the latest release (version ""false"")" -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"Pasting from an external source into the edit summary box works fine for me." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"To reproduce:\n1." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"Load any page in VisualEditor." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"2." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"Do any of\n i." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"Press the browser back button to exit VE\n ii." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"Cancel the edit\n iii." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"make an edit and then save the page\n3." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"Select any text anywhere on the page and copy it to the clipboard\n4." -45,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",1379683839,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-m5xhygyqlxkvxhsdd6xe","task_subcomment","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted","Pasting from an external source into the edit summary box works fine for me. - -However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. - -To reproduce: -1. Load any page in VisualEditor. -2. Do any of - i. Press the browser back button to exit VE - ii. Cancel the edit - iii. make an edit and then save the page -3. Select any text anywhere on the page and copy it to the clipboard -4. Try to paste that text anywhere (search box, URL bar, text editor, etc) - -Expected behaviour: Selected text is copied and pasted -Actual behaviour: Selected text is not copied and pasted",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Pasting from an external source into the edit summary box works fine for me.', 'However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE.', 'To reproduce:\n1.', 'Load any page in VisualEditor.', '2.', 'Do any of\n i.', 'Press the browser back button to exit VE\n ii.', 'Cancel the edit\n iii.', 'make an edit and then save the page\n3.', 'Select any text anywhere on the page and copy it to the clipboard\n4.', 'Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted']",NA,0,"Try to paste that text anywhere (search box, URL bar, text editor, etc)\n\nExpected behaviour: Selected text is copied and pasted\nActual behaviour: Selected text is not copied and pasted" -217,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","screenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}",1372931040,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_description","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","Unbreak Now!",100,1373053892,NA,"resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded).', 'screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit]).', ""They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top."", 'See screenshot.', 'Observed on en.wp (by me and User:KTC) and fr.wp (by me).', 'KTC used firefox and chrome, and I used firefox 21.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}']",TRUE,0,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)." -217,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","screenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}",1372931040,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_description","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","Unbreak Now!",100,1373053892,NA,"resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded).', 'screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit]).', ""They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top."", 'See screenshot.', 'Observed on en.wp (by me and User:KTC) and fr.wp (by me).', 'KTC used firefox and chrome, and I used firefox 21.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}']",TRUE,0,"screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit])." -217,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","screenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}",1372931040,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_description","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","Unbreak Now!",100,1373053892,NA,"resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded).', 'screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit]).', ""They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top."", 'See screenshot.', 'Observed on en.wp (by me and User:KTC) and fr.wp (by me).', 'KTC used firefox and chrome, and I used firefox 21.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}']",TRUE,0,"See screenshot." -217,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","screenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}",1372931040,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_description","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","Unbreak Now!",100,1373053892,NA,"resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded).', 'screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit]).', ""They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top."", 'See screenshot.', 'Observed on en.wp (by me and User:KTC) and fr.wp (by me).', 'KTC used firefox and chrome, and I used firefox 21.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}']",TRUE,0,"Observed on en.wp (by me and User:KTC) and fr.wp (by me)." -217,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","screenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}",1372931040,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_description","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","Unbreak Now!",100,1373053892,NA,"resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded).', 'screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit]).', ""They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top."", 'See screenshot.', 'Observed on en.wp (by me and User:KTC) and fr.wp (by me).', 'KTC used firefox and chrome, and I used firefox 21.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}']",TRUE,0,"KTC used firefox and chrome, and I used firefox 21." -217,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","screenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}",1372931040,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_description","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","Unbreak Now!",100,1373053892,NA,"resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded).', 'screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit]).', ""They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top."", 'See screenshot.', 'Observed on en.wp (by me and User:KTC) and fr.wp (by me).', 'KTC used firefox and chrome, and I used firefox 21.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}" -217,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","screenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}",1372931040,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_description","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)./n/nscreenshot - -As of today, the section edit links seem to have reverted to the old style ([edit]). They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top. See screenshot. - -Observed on en.wp (by me and User:KTC) and fr.wp (by me). KTC used firefox and chrome, and I used firefox 21. - --------------------------- -**Version**: unspecified -**Severity**: major - -**Attached**: {F11031}","Unbreak Now!",100,1373053892,NA,"resolved","True","c1",3,"False","False",0,NA,"['VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded).', 'screenshot\n\nAs of today, the section edit links seem to have reverted to the old style ([edit]).', ""They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top."", 'See screenshot.', 'Observed on en.wp (by me and User:KTC) and fr.wp (by me).', 'KTC used firefox and chrome, and I used firefox 21.', '--------------------------\n**Version**: unspecified\n**Severity**: major\n\n**Attached**: {F11031}']",TRUE,0,"They don't expand and they open the source editor, even though VE is enabled (the 'Edit' and 'Edit source' tabs are there at the top." -218,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Merged and will hopefully go out soon.",1373053892,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Merged and will hopefully go out soon.","Merged and will hopefully go out soon.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"['Merged and will hopefully go out soon.']",NA,0,"Merged and will hopefully go out soon." -219,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Change 72069 merged by jenkins-bot: -mw.ViewPageTarget.init: Move edit section to top init - -https://gerrit.wikimedia.org/r/72069",1373049617,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Change 72069 merged by jenkins-bot: -mw.ViewPageTarget.init: Move edit section to top init - -https://gerrit.wikimedia.org/r/72069","Change 72069 merged by jenkins-bot: -mw.ViewPageTarget.init: Move edit section to top init - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Change 72069 merged by jenkins-bot:\nmw.ViewPageTarget.init: Move edit section to top init\n\nGERRIT_URL']",NA,0,"Change 72069 merged by jenkins-bot:\nmw.ViewPageTarget.init: Move edit section to top init\n\nGERRIT_URL" -220,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",1373016135,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Please consider fixing bug 50540 and maybe bug 50405, too.', 'They are directly dependent of this change.', 'Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth.', 'Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.']",NA,0,"Please consider fixing bug 50540 and maybe bug 50405, too." -220,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",1373016135,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Please consider fixing bug 50540 and maybe bug 50405, too.', 'They are directly dependent of this change.', 'Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth.', 'Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.']",NA,0,"They are directly dependent of this change." -220,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",1373016135,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Please consider fixing bug 50540 and maybe bug 50405, too.', 'They are directly dependent of this change.', 'Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth.', 'Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.']",NA,0,"Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth." -220,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",1373016135,"PHID-USER-v3yn5qf233ggnnnmvejc","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.","Please consider fixing bug 50540 and maybe bug 50405, too. - -They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. - -Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Please consider fixing bug 50540 and maybe bug 50405, too.', 'They are directly dependent of this change.', 'Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth.', 'Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.']",NA,0,"Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect." -221,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Change 72069 had a related patch set uploaded by Krinkle: -mw.ViewPageTarget.init: Move edit section to top init. - -https://gerrit.wikimedia.org/r/72069",1373004125,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Change 72069 had a related patch set uploaded by Krinkle: -mw.ViewPageTarget.init: Move edit section to top init. - -https://gerrit.wikimedia.org/r/72069","Change 72069 had a related patch set uploaded by Krinkle: -mw.ViewPageTarget.init: Move edit section to top init. - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Change 72069 had a related patch set uploaded by Krinkle:\nmw.ViewPageTarget.init: Move edit section to top init.', 'GERRIT_URL']",NA,0,"Change 72069 had a related patch set uploaded by Krinkle:\nmw.ViewPageTarget.init: Move edit section to top init." -221,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Change 72069 had a related patch set uploaded by Krinkle: -mw.ViewPageTarget.init: Move edit section to top init. - -https://gerrit.wikimedia.org/r/72069",1373004125,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Change 72069 had a related patch set uploaded by Krinkle: -mw.ViewPageTarget.init: Move edit section to top init. - -https://gerrit.wikimedia.org/r/72069","Change 72069 had a related patch set uploaded by Krinkle: -mw.ViewPageTarget.init: Move edit section to top init. - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Change 72069 had a related patch set uploaded by Krinkle:\nmw.ViewPageTarget.init: Move edit section to top init.', 'GERRIT_URL']",NA,0,"GERRIT_URL" -222,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Bizarrely, the mouseover ""edit source"" links appear briefly when mousing over ""edit"" links while VE is loading a page into edit mode.",1372969315,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Bizarrely, the mouseover ""edit source"" links appear briefly when mousing over ""edit"" links while VE is loading a page into edit mode.","Bizarrely, the mouseover ""edit source"" links appear briefly when mousing over ""edit"" links while VE is loading a page into edit mode.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Bizarrely, the mouseover ""edit source"" links appear briefly when mousing over ""edit"" links while VE is loading a page into edit mode.']",NA,0,"Bizarrely, the mouseover ""edit source"" links appear briefly when mousing over ""edit"" links while VE is loading a page into edit mode." -223,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon.",1372952624,"PHID-USER-gfaq55vdypjmzz6nl2kn","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon.","Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"[""Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon.""]",NA,0,"Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon." -224,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",1372952431,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Well, if that\'s the case (I haven\'t heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs.', 'Otherwise, I expect quite a bit of confusion.']",NA,0,"Well, if that\" -224,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",1372952431,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Well, if that\'s the case (I haven\'t heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs.', 'Otherwise, I expect quite a bit of confusion.']",NA,0,"t heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs." -224,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",1372952431,"PHID-USER-z6nzrwuaij3spgyg23jt","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"['Well, if that\'s the case (I haven\'t heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs.', 'Otherwise, I expect quite a bit of confusion.']",NA,0,"Otherwise, I expect quite a bit of confusion." -225,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.",1372951540,"PHID-USER-gfaq55vdypjmzz6nl2kn","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.","I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"[""I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future."", ""So we now don't have an interface that claims functionality there aren't even plans to implement.""]",NA,0,"I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future." -225,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.",1372951540,"PHID-USER-gfaq55vdypjmzz6nl2kn","PHID-TASK-b5zzf7lh657agk5cdqkw","task_subcomment","I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.","I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,0,NA,"[""I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future."", ""So we now don't have an interface that claims functionality there aren't even plans to implement.""]",NA,0,"So we now don't have an interface that claims functionality there aren't even plans to implement." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"1." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Create a page that has a heading at the very beginning\n2." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Open it in VE\n3." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Put the cursor at the beginning of the heading and press Enter\n4." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"An empty heading appears above\n5." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Use arrow keys or mouse to move the cursor into this empty heading\n6." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"See an error in the console\n7." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Type into the heading\n8." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly." -552,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal",1368667200,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-5refjnnnoyqumq4ge53g","task_description","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox./n/n1. Create a page that has a heading at the very beginning -2. Open it in VE -3. Put the cursor at the beginning of the heading and press Enter -4. An empty heading appears above -5. Use arrow keys or mouse to move the cursor into this empty heading -6. See an error in the console -7. Type into the heading -8. See one error per key press in the console - -In Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly. - --------------------------- -**Version**: unspecified -**Severity**: normal","Unbreak Now!",100,1371602123,NA,"resolved","True","c1",1,"False","False",-7,NA,"['VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox.', '1.', 'Create a page that has a heading at the very beginning\n2.', 'Open it in VE\n3.', 'Put the cursor at the beginning of the heading and press Enter\n4.', 'An empty heading appears above\n5.', 'Use arrow keys or mouse to move the cursor into this empty heading\n6.', 'See an error in the console\n7.', 'Type into the heading\n8.', 'See one error per key press in the console\n\nIn Chrome, this behaves correctly: it creates a paragraph above the heading, and typing into it works correctly.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" -553,"VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox","This is not an issue anymore.",1371602123,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-5refjnnnoyqumq4ge53g","task_subcomment","This is not an issue anymore.","This is not an issue anymore.",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-2,NA,"['This is not an issue anymore.']",NA,0,"This is not an issue anymore." -640,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. +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**: -http://bugs.jquery.com/ticket/13821",1366992360,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_description","VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest./n/njQuery have WONTFIX'ed this bug (13821) so we'll have to work around. +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**: -http://bugs.jquery.com/ticket/13821","VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest./n/njQuery have WONTFIX'ed this bug (13821) so we'll have to work around. +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","Unbreak Now!",100,1367097148,NA,"resolved","True","c1",1,"True","False",-10,NA,"['VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest.', ""jQuery have WONTFIX'ed this bug (13821) so we'll have to work around."", '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",TRUE,0,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest." -640,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - --------------------------- -**Version**: unspecified -**Severity**: major -**See Also**: -http://bugs.jquery.com/ticket/13821",1366992360,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_description","VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest./n/njQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - --------------------------- -**Version**: unspecified -**Severity**: major -**See Also**: -http://bugs.jquery.com/ticket/13821","VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest./n/njQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - --------------------------- -**Version**: unspecified -**Severity**: major -**See Also**: -URL","Unbreak Now!",100,1367097148,NA,"resolved","True","c1",1,"True","False",-10,NA,"['VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest.', ""jQuery have WONTFIX'ed this bug (13821) so we'll have to work around."", '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL" -640,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - --------------------------- -**Version**: unspecified -**Severity**: major -**See Also**: -http://bugs.jquery.com/ticket/13821",1366992360,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_description","VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest./n/njQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - --------------------------- -**Version**: unspecified -**Severity**: major -**See Also**: -http://bugs.jquery.com/ticket/13821","VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest./n/njQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - --------------------------- -**Version**: unspecified -**Severity**: major -**See Also**: -URL","Unbreak Now!",100,1367097148,NA,"resolved","True","c1",1,"True","False",-10,NA,"['VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest.', ""jQuery have WONTFIX'ed this bug (13821) so we'll have to work around."", '--------------------------\n**Version**: unspecified\n**Severity**: major\n**See Also**:\nURL']",TRUE,0,"jQuery have WONTFIX'ed this bug (13821) so we'll have to work around." -641,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","(In reply to comment #5) -> (In reply to comment #0) -> > jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. -> -> Any link? http://bugs.jquery.com/report/13821 returns error. - -http://bugs.jquery.com/ticket/13821 (in the see also field).",1367595136,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","(In reply to comment #5) -> (In reply to comment #0) -> > jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. -> -> Any link? http://bugs.jquery.com/report/13821 returns error. - -http://bugs.jquery.com/ticket/13821 (in the see also field).","(In reply to comment #5) -QUOTE -QUOTE -QUOTE -QUOTE - -URL (in the see also field).",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nURL (in the see also field).']",NA,0,"(In reply to comment #5)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nURL (in the see also field)." -642,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","Another place we had to work around: -https://gerrit.wikimedia.org/r/#/c/62028/",1367577189,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","Another place we had to work around: -https://gerrit.wikimedia.org/r/#/c/62028/","Another place we had to work around: -URL",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['Another place we had to work around:\nURL']",NA,0,"Another place we had to work around:\nURL" -643,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","(In reply to comment #0) -> jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - -Any link? http://bugs.jquery.com/report/13821 returns error.",1367562927,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","(In reply to comment #0) -> jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - -Any link? http://bugs.jquery.com/report/13821 returns error.","(In reply to comment #0) -QUOTE - -Any link? URL returns error.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-9,NA,"['(In reply to comment #0)\nQUOTE\n\nAny link?', 'URL returns error.']",NA,0,"(In reply to comment #0)\nQUOTE\n\nAny link?" -643,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","(In reply to comment #0) -> jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - -Any link? http://bugs.jquery.com/report/13821 returns error.",1367562927,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","(In reply to comment #0) -> jQuery have WONTFIX'ed this bug (13821) so we'll have to work around. - -Any link? http://bugs.jquery.com/report/13821 returns error.","(In reply to comment #0) -QUOTE - -Any link? URL returns error.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-9,NA,"['(In reply to comment #0)\nQUOTE\n\nAny link?', 'URL returns error.']",NA,0,"URL returns error." -644,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","*** Bug 47860 has been marked as a duplicate of this bug. ***",1367545048,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","*** Bug 47860 has been marked as a duplicate of this bug. ***","*** Bug 47860 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['*** Bug 47860 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 47860 has been marked as a duplicate of this bug." -644,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","*** Bug 47860 has been marked as a duplicate of this bug. ***",1367545048,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","*** Bug 47860 has been marked as a duplicate of this bug. ***","*** Bug 47860 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['*** Bug 47860 has been marked as a duplicate of this bug.', '***']",NA,0,"***" -645,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","Ed's code is merged and will be going out with the regular deployment train on Monday.",1367097148,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","Ed's code is merged and will be going out with the regular deployment train on Monday.","Ed's code is merged and will be going out with the regular deployment train on Monday.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"[""Ed's code is merged and will be going out with the regular deployment train on Monday.""]",NA,0,"Ed's code is merged and will be going out with the regular deployment train on Monday." -646,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","Related URL: https://gerrit.wikimedia.org/r/61180 (Gerrit Change I3df8f49b170c31da9610129d53cf8cb65dd5d5f8)",1367066588,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/61180 (Gerrit Change I3df8f49b170c31da9610129d53cf8cb65dd5d5f8)","Related URL: GERRIT_URL (Gerrit Change I3df8f49b170c31da9610129d53cf8cb65dd5d5f8)",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-10,NA,"['Related URL: GERRIT_URL (Gerrit Change I3df8f49b170c31da9610129d53cf8cb65dd5d5f8)']",NA,0,"Related URL: GERRIT_URL (Gerrit Change I3df8f49b170c31da9610129d53cf8cb65dd5d5f8)" -647,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","*** Bug 47712 has been marked as a duplicate of this bug. ***",1366992520,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","*** Bug 47712 has been marked as a duplicate of this bug. ***","*** Bug 47712 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['*** Bug 47712 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 47712 has been marked as a duplicate of this bug." -647,"VisualEditor: jQuery bug in regex matching causes corruption of data-parsoid on ingest","*** Bug 47712 has been marked as a duplicate of this bug. ***",1366992520,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-5bwy7gci6gdsa3r3m24i","task_subcomment","*** Bug 47712 has been marked as a duplicate of this bug. ***","*** Bug 47712 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['*** Bug 47712 has been marked as a duplicate of this bug.', '***']",NA,0,"***" -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: (silently) renumbering references." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"I was certain to follow the Save Changes procedure, but many different references reverted to the same single reference." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"[...] Same bug today." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"In VE, I placed the cursor in the text, chose ""Reference"" from the ""More"" menu, added a reference, (It appeared as it should with the appropriate numerical superscript), Saved the work, returned to check the page...references disappeared from the list." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"- Window 8, Chrome >>." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"TeamGale adds:\n<> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"I only saw it when I saved the article and the number of the references had decreased." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"This URL is the change I was doing when it happened." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Could it be related to editing a table with beta?" -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"After I re-added the references and the new table, every time I click ""edit beta"" the refs are gone!" -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Before I even do any change!" -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Just wanted to say that this is happening to other articles as well." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"That would be a problem to a long article with lots of references... Mozilla 21, Windows 8.>>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"This time I saved the edit just to post it here." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"URL [...] \nUpdate: Tables were a coincidence." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"I didn't realized that it happened while I was editing." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Probably not since I don't see any table on Christopher Thurber's article." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Basically I can't use beta at all on this article!" -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"I don't have any issues using the source but, if it's something simple that can be done with beta, I prefer to do it with it." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"But I can't." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"And it's possible to happen and people don't see it." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"It happened to me again in main article's text." -776,"VisualEditor: (silently) renumbering references","Sherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1380214860,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-gjqblxpe4th4o7zcpret","task_description","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, https://en.wikipedia.org/w/index.php?title=Homesickness&diff=573215056&oldid=573214608 : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. https://en.wikipedia.org/w/index.php?title=Dancing_with_the_Stars_%28U.S._season_17%29&diff=prev&oldid=574412488 [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: (silently) renumbering references./n/nSherry describes what happens in this edit, URL : -<<[this edit] is the original problem. It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>> - -The original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce: -<>. - -TeamGale adds: -<> - -TeamGale again: -<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one. This time I saved the edit just to post it here. URL [...] -Update: Tables were a coincidence. It happened to me again in main article's text. I didn't save the edit this time...>> - -I think I saw this renumbering issue at it.wp as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1380220185,NA,"resolved","True","c1",3,"False","False",12,NA,"['VisualEditor: (silently) renumbering references.', 'Sherry describes what happens in this edit, URL :\n<<[this edit] is the original problem.', 'It gave all of those references the same ""name"" (""ref name="":4""""), which convinced the software using for viewing pages that they were all the same ref.>>\n\nThe original reporter, Christopher Thurber, describes the issue, and provides some hints to reproduce:\n<>.', 'TeamGale adds:\n<>\n\nTeamGale again:\n<<[...] every time I am trying to add a reference at a table with VE, it changes it and replaces it with an already existent one.', 'This time I saved the edit just to post it here.', 'URL [...] \nUpdate: Tables were a coincidence.', ""It happened to me again in main article's text."", ""I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"I didn't save the edit this time...>>\n\nI think I saw this renumbering issue at it.wp as well." -777,"VisualEditor: (silently) renumbering references","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***",1380220185,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gjqblxpe4th4o7zcpret","task_subcomment","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['Yeah, this was a bad bug - bug 54341.', ""We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry!"", '*** This bug has been marked as a duplicate of bug 54341 ***']",NA,0,"Yeah, this was a bad bug - bug 54341." -777,"VisualEditor: (silently) renumbering references","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***",1380220185,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gjqblxpe4th4o7zcpret","task_subcomment","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['Yeah, this was a bad bug - bug 54341.', ""We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry!"", '*** This bug has been marked as a duplicate of bug 54341 ***']",NA,0,"*** This bug has been marked as a duplicate of bug 54341 ***" -777,"VisualEditor: (silently) renumbering references","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***",1380220185,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gjqblxpe4th4o7zcpret","task_subcomment","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***","Yeah, this was a bad bug - bug 54341. We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry! - -*** This bug has been marked as a duplicate of bug 54341 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,12,NA,"['Yeah, this was a bad bug - bug 54341.', ""We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry!"", '*** This bug has been marked as a duplicate of bug 54341 ***']",NA,0,"We fixed it on Tuesday, and back-ported it to production yesterday, so this shouldn't happen again; sorry!" -1197,"VisualEditor or Parsoid: Breaks and partially duplicates html tag","en.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal",1374877200,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-oqjy24dqtbqambra54dm","task_description","VisualEditor or Parsoid: Breaks and partially duplicates html tag./n/nen.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor or Parsoid: Breaks and partially duplicates html tag./n/nen.wp editor DragonsFlight reports a strange diff at URL where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1379848985,NA,"declined","True","c1",3,"False","False",3,NA,"['VisualEditor or Parsoid: Breaks and partially duplicates html tag.', 'en.wp editor DragonsFlight reports a strange diff at URL where a
was duplicated minus the leading <\n\nPossibly related to bug 51304?', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"VisualEditor or Parsoid: Breaks and partially duplicates html tag." -1197,"VisualEditor or Parsoid: Breaks and partially duplicates html tag","en.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal",1374877200,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-oqjy24dqtbqambra54dm","task_description","VisualEditor or Parsoid: Breaks and partially duplicates html tag./n/nen.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor or Parsoid: Breaks and partially duplicates html tag./n/nen.wp editor DragonsFlight reports a strange diff at URL where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1379848985,NA,"declined","True","c1",3,"False","False",3,NA,"['VisualEditor or Parsoid: Breaks and partially duplicates html tag.', 'en.wp editor DragonsFlight reports a strange diff at URL where a
was duplicated minus the leading <\n\nPossibly related to bug 51304?', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"en.wp editor DragonsFlight reports a strange diff at URL where a
was duplicated minus the leading <\n\nPossibly related to bug 51304?" -1197,"VisualEditor or Parsoid: Breaks and partially duplicates html tag","en.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal",1374877200,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-oqjy24dqtbqambra54dm","task_description","VisualEditor or Parsoid: Breaks and partially duplicates html tag./n/nen.wp editor DragonsFlight reports a strange diff at https://en.wikipedia.org/w/index.php?title=Axial_precession&diff=next&oldid=565790907 where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor or Parsoid: Breaks and partially duplicates html tag./n/nen.wp editor DragonsFlight reports a strange diff at URL where a
was duplicated minus the leading < - -Possibly related to bug 51304? - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1379848985,NA,"declined","True","c1",3,"False","False",3,NA,"['VisualEditor or Parsoid: Breaks and partially duplicates html tag.', 'en.wp editor DragonsFlight reports a strange diff at URL where a
was duplicated minus the leading <\n\nPossibly related to bug 51304?', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"--------------------------\n**Version**: unspecified\n**Severity**: normal" -1198,"VisualEditor or Parsoid: Breaks and partially duplicates html tag","Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.",1379848985,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-oqjy24dqtbqambra54dm","task_subcomment","Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.","Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,11,NA,"[""Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue."", 'Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.']",NA,1,"Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available." -1198,"VisualEditor or Parsoid: Breaks and partially duplicates html tag","Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.",1379848985,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-oqjy24dqtbqambra54dm","task_subcomment","Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.","Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,11,NA,"[""Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue."", 'Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.']",NA,1,"Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue." -1199,"VisualEditor or Parsoid: Breaks and partially duplicates html tag","Given the proximity of the image, im guessing this is bug 52107.",1375737774,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-oqjy24dqtbqambra54dm","task_subcomment","Given the proximity of the image, im guessing this is bug 52107.","Given the proximity of the image, im guessing this is bug 52107.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['Given the proximity of the image, im guessing this is bug 52107.']",NA,1,"Given the proximity of the image, im guessing this is bug 52107." -1563,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) - -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used links..."") - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160",1373324220,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-atyu2v5fwwehteymmmkf","task_description","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) - -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used links..."") - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as URL -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -URL","Needs Triage",90,1486157050,"PHID-USER-ydswvwhh5pm4lshahjje","duplicate","True","c1",3,"False","False",1,NA,"['VisualEditor should not encourage links of little relevance (e.g.', 'disambiguation pages, already used links, etc..).', '1) Open an article such as\nURL\n2) Click in a non-linked word ""function""\n3) Click in the link button (CTRL+K)\n\nThe list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided.', 'Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g.', 'by having a section in the dropdown menu labeled ""Already used links..."")\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"VisualEditor should not encourage links of little relevance (e.g." -1563,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160",1373324220,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-atyu2v5fwwehteymmmkf","task_description","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as URL -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -URL","Needs Triage",90,1486157050,"PHID-USER-ydswvwhh5pm4lshahjje","duplicate","True","c1",3,"False","False",1,NA,"['VisualEditor should not encourage links of little relevance (e.g.', 'disambiguation pages, already used links, etc..).', '1) Open an article such as\nURL\n2) Click in a non-linked word ""function""\n3) Click in the link button (CTRL+K)\n\nThe list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided.', 'Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g.', 'by having a section in the dropdown menu labeled ""Already used links..."")\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"disambiguation pages, already used links, etc..)." -1563,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160",1373324220,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-atyu2v5fwwehteymmmkf","task_description","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as URL -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -URL","Needs Triage",90,1486157050,"PHID-USER-ydswvwhh5pm4lshahjje","duplicate","True","c1",3,"False","False",1,NA,"['VisualEditor should not encourage links of little relevance (e.g.', 'disambiguation pages, already used links, etc..).', '1) Open an article such as\nURL\n2) Click in a non-linked word ""function""\n3) Click in the link button (CTRL+K)\n\nThe list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided.', 'Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g.', 'by having a section in the dropdown menu labeled ""Already used links..."")\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"1) Open an article such as\nURL\n2) Click in a non-linked word ""function""\n3) Click in the link button (CTRL+K)\n\nThe list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided." -1563,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160",1373324220,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-atyu2v5fwwehteymmmkf","task_description","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as URL -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -URL","Needs Triage",90,1486157050,"PHID-USER-ydswvwhh5pm4lshahjje","duplicate","True","c1",3,"False","False",1,NA,"['VisualEditor should not encourage links of little relevance (e.g.', 'disambiguation pages, already used links, etc..).', '1) Open an article such as\nURL\n2) Click in a non-linked word ""function""\n3) Click in the link button (CTRL+K)\n\nThe list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided.', 'Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g.', 'by having a section in the dropdown menu labeled ""Already used links..."")\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g." -1563,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160",1373324220,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-atyu2v5fwwehteymmmkf","task_description","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as -https://en.wikipedia.org/wiki/Convex_function?veaction=edit -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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. -The list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. - -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used 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**: normal +**Severity**: major **See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=50160","VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)./n/n1) Open an article such as URL -2) Click in a non-linked word ""function"" -3) Click in the link button (CTRL+K) +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 list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided. +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 -Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g. by having a section in the dropdown menu labeled ""Already used links..."") +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**: normal -**See Also**: -URL","Needs Triage",90,1486157050,"PHID-USER-ydswvwhh5pm4lshahjje","duplicate","True","c1",3,"False","False",1,NA,"['VisualEditor should not encourage links of little relevance (e.g.', 'disambiguation pages, already used links, etc..).', '1) Open an article such as\nURL\n2) Click in a non-linked word ""function""\n3) Click in the link button (CTRL+K)\n\nThe list of matching pages will include the disambiguation page ""[[Function]]"", which should actually be avoided.', 'Similarly, if a paragraph already has a link to [[Function]], then it should not appear in a second atempt to add the same link (or there should be some visual indication that this kind of link is not desirable - e.g.', 'by having a section in the dropdown menu labeled ""Already used links..."")\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"by having a section in the dropdown menu labeled ""Already used links..."")\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL" -1564,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon. - -*** This bug has been marked as a duplicate of bug 50240 ***",1373472822,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-atyu2v5fwwehteymmmkf","task_subcomment","This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon. - -*** This bug has been marked as a duplicate of bug 50240 ***","This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon. - -*** This bug has been marked as a duplicate of bug 50240 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon.', '*** This bug has been marked as a duplicate of bug 50240 ***']",NA,0,"This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon." -1564,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon. - -*** This bug has been marked as a duplicate of bug 50240 ***",1373472822,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-atyu2v5fwwehteymmmkf","task_subcomment","This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon. - -*** This bug has been marked as a duplicate of bug 50240 ***","This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon. - -*** This bug has been marked as a duplicate of bug 50240 ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon.', '*** This bug has been marked as a duplicate of bug 50240 ***']",NA,0,"*** This bug has been marked as a duplicate of bug 50240 ***" -1565,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","See also gerrit change 70564.",1373469016,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-atyu2v5fwwehteymmmkf","task_subcomment","See also gerrit change 70564.","See also gerrit change 70564.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['See also gerrit change 70564.']",NA,0,"See also gerrit change 70564." -1566,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","PS: this was inspired by the commit message of -https://gerrit.wikimedia.org/r/#/c/72646/",1373325997,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-atyu2v5fwwehteymmmkf","task_subcomment","PS: this was inspired by the commit message of -https://gerrit.wikimedia.org/r/#/c/72646/","PS: this was inspired by the commit message of -URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['PS: this was inspired by the commit message of\nURL']",NA,0,"PS: this was inspired by the commit message of\nURL" -1600,"Keyboard shortcut for editing source","With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal",1373048100,"PHID-USER-fwlidikyeorzj35hufwu","PHID-TASK-gqozvzrj5ka3lgyouwvn","task_description","Keyboard shortcut for editing source./n/nWith VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal","Keyboard shortcut for editing source./n/nWith VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal","Needs Triage",90,1373077734,NA,"resolved","True","c1",3,"False","False",0,NA,"['Keyboard shortcut for editing source.', 'With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page.', 'Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Keyboard shortcut for editing source." -1600,"Keyboard shortcut for editing source","With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal",1373048100,"PHID-USER-fwlidikyeorzj35hufwu","PHID-TASK-gqozvzrj5ka3lgyouwvn","task_description","Keyboard shortcut for editing source./n/nWith VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal","Keyboard shortcut for editing source./n/nWith VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal","Needs Triage",90,1373077734,NA,"resolved","True","c1",3,"False","False",0,NA,"['Keyboard shortcut for editing source.', 'With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page.', 'Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page." -1600,"Keyboard shortcut for editing source","With VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal",1373048100,"PHID-USER-fwlidikyeorzj35hufwu","PHID-TASK-gqozvzrj5ka3lgyouwvn","task_description","Keyboard shortcut for editing source./n/nWith VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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**: normal","Keyboard shortcut for editing source./n/nWith VisualEditor enabled the shortcut alt+shift+e no longer works, which previously opened the ""edit source"" page. Considering many users work without a mouse on a laptop, it would be beneficial to have this enabled. +**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: and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal",1367290980,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-slnchzhtiw4uoxg47vla","task_description","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nhttps://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213 - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nURL - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1367545048,NA,"resolved","True","c1",1,"False","False",-9,NA,"['VisualEditor: Extra tags got inserted causing infobox layout to be broken.', 'URL\n\nAll change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically.', 'Where\'s that ""partial serialization"" mentioned before?', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"VisualEditor: Extra tags got inserted causing infobox layout to be broken." -2108,"VisualEditor: Extra tags got inserted causing infobox layout to be broken","https://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213 - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal",1367290980,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-slnchzhtiw4uoxg47vla","task_description","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nhttps://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213 - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nURL - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1367545048,NA,"resolved","True","c1",1,"False","False",-9,NA,"['VisualEditor: Extra tags got inserted causing infobox layout to be broken.', 'URL\n\nAll change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically.', 'Where\'s that ""partial serialization"" mentioned before?', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"URL\n\nAll change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically." -2108,"VisualEditor: Extra tags got inserted causing infobox layout to be broken","https://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213 - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal",1367290980,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-slnchzhtiw4uoxg47vla","task_description","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nhttps://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213 - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nURL - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1367545048,NA,"resolved","True","c1",1,"False","False",-9,NA,"['VisualEditor: Extra tags got inserted causing infobox layout to be broken.', 'URL\n\nAll change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically.', 'Where\'s that ""partial serialization"" mentioned before?', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"Where\" -2108,"VisualEditor: Extra tags got inserted causing infobox layout to be broken","https://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213 - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal",1367290980,"PHID-USER-zjzhrhmn36icnzbckqy4","PHID-TASK-slnchzhtiw4uoxg47vla","task_description","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nhttps://zh.wikipedia.org/w/index.php?title=Team_A_6th_Stage%E3%80%8C%E7%9B%AE%E6%93%8A%E8%80%85%E3%80%8D&diff=26390481&oldid=25589213 - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Extra tags got inserted causing infobox layout to be broken./n/nURL - -All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. - -Where's that ""partial serialization"" mentioned before? - --------------------------- -**Version**: unspecified -**Severity**: normal","Needs Triage",90,1367545048,NA,"resolved","True","c1",1,"False","False",-9,NA,"['VisualEditor: Extra tags got inserted causing infobox layout to be broken.', 'URL\n\nAll change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically.', 'Where\'s that ""partial serialization"" mentioned before?', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,1,"partial serialization" -2109,"VisualEditor: Extra tags got inserted causing infobox layout to be broken","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",1367545048,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-slnchzhtiw4uoxg47vla","task_subcomment","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May."", 'The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor).', 'Marking as a dupe.', '*** This bug has been marked as a duplicate of bug 47737 ***']",NA,1,"The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor)." -2109,"VisualEditor: Extra tags got inserted causing infobox layout to be broken","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",1367545048,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-slnchzhtiw4uoxg47vla","task_subcomment","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May."", 'The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor).', 'Marking as a dupe.', '*** This bug has been marked as a duplicate of bug 47737 ***']",NA,1,"Marking as a dupe." -2109,"VisualEditor: Extra tags got inserted causing infobox layout to be broken","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",1367545048,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-slnchzhtiw4uoxg47vla","task_subcomment","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May."", 'The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor).', 'Marking as a dupe.', '*** This bug has been marked as a duplicate of bug 47737 ***']",NA,1,"*** This bug has been marked as a duplicate of bug 47737 ***" -2109,"VisualEditor: Extra tags got inserted causing infobox layout to be broken","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",1367545048,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-slnchzhtiw4uoxg47vla","task_subcomment","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***","The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. - -The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). - -Marking as a dupe. - -*** This bug has been marked as a duplicate of bug 47737 ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"[""The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May."", 'The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor).', 'Marking as a dupe.', '*** This bug has been marked as a duplicate of bug 47737 ***']",NA,1,"The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"See the URL for a demo." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"In the output page it is shown as ""1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"A""." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"In the VE it is shown as\n1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"1." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"A\n\nThis is an edge case but it should should probably be identical in any case." -2121,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","See the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes",1367008080,"PHID-USER-xfe43w2lb5gpvglf4coa","PHID-TASK-exyn4bfiq2igip2xy6r4","task_description","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: https://www.mediawiki.org/wiki/VisualEditor:Multiple_hashes","A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page./n/nSee the URL for a demo. - -The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning. - -In the output page it is shown as ""1. 1. 1. 1. 1. 1. 1. A"". - -In the VE it is shown as -1. - 1. - 1. - 1. - 1. - 1. - 1. A - -This is an edge case but it should should probably be identical in any case. - --------------------------- -**Version**: unspecified -**Severity**: normal -**URL**: URL","Needs Triage",90,1367009441,NA,"declined","True","c1",1,"False","False",-10,NA,"['A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page.', 'See the URL for a demo.', 'The last line in the source of the demo page has an empty paragraph before it and several hash marks in the beginning.', 'In the output page it is shown as ""1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A"".', 'In the VE it is shown as\n1.', '1.', '1.', '1.', '1.', '1.', '1.', 'A\n\nThis is an edge case but it should should probably be identical in any case.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL" -2122,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.",1367019704,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-exyn4bfiq2igip2xy6r4","task_subcomment","Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.","Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['Confirm that this is intentional behaviour.', ""There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.""]",NA,0,"Confirm that this is intentional behaviour." -2122,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.",1367019704,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-exyn4bfiq2igip2xy6r4","task_subcomment","Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.","Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['Confirm that this is intentional behaviour.', ""There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.""]",NA,0,"There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing." -2123,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).",1367009441,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-exyn4bfiq2igip2xy6r4","task_subcomment","As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).","As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-10,NA,"[""As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level."", ""James - please confirm (and reopen if I'm wrong).""]",NA,0,"As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level." -2123,"A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page","As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).",1367009441,"PHID-USER-s7sn3zjthnxvep34c5ho","PHID-TASK-exyn4bfiq2igip2xy6r4","task_subcomment","As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).","As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-10,NA,"[""As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level."", ""James - please confirm (and reopen if I'm wrong).""]",NA,0,"James - please confirm (and reopen if I'm wrong)." -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,"**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \" -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,", 2500 );\n define( \" -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,", 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \" -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,";\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \" -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,";\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\" -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,"] = 1;\n $wgHiddenPrefs[] = \" -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,";\n $wgVisualEditorParsoidURL = \" -2207,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html",1359038700,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_description","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** `mail` - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'http://parsoid.wmflabs.org/'; - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html","Parsoid should support passing on an authenticated user's read right (when MW API supports that)./n/n**Author:** CODE - -**Description:** -Hi, - -when I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error: - - {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}} - -My config is as following: - - require_once(""$IP/extensions/VisualEditor/VisualEditor.php""); - define( 'NS_VISUALEDITOR', 2500 ); - define( 'NS_VISUALEDITOR_TALK', 2501 ); - $wgExtraNamespaces[NS_VISUALEDITOR] = 'VisualEditor'; - $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = 'VisualEditor_talk'; - $wgVisualEditorNamespaces = array( NS_MAIN ); - $wgVisualEditorNamespaces = array(); - $wgVisualEditorNamespaces[] = NS_VISUALEDITOR; - $wgDefaultUserOptions['visualeditor-enable'] = 1; - $wgHiddenPrefs[] = 'visualeditor-enable'; - $wgVisualEditorParsoidURL = 'URL - -I installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013). - --------------------------- -**Version**: unspecified -**Severity**: normal -**OS**: Linux -**Platform**: PC -**URL**: URL","Needs Triage",90,1360207511,NA,"resolved","True","c1",1,"False","False",-23,NA,"[""Parsoid should support passing on an authenticated user's read right (when MW API supports that)."", '**Author:** CODE\n\n**Description:**\nHi,\n\nwhen I click on the WYSIWYG button on /w/VisualEditor:Sandbox (existsting page), I only get an error:\n\n {""error"":{""code"":""parsoidserver"",""info"":""Error contacting the Parsoid server""}}\n\nMy config is as following:\n\n require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");\n define( \'NS_VISUALEDITOR\', 2500 );\n define( \'NS_VISUALEDITOR_TALK\', 2501 );\n $wgExtraNamespaces[NS_VISUALEDITOR] = \'VisualEditor\';\n $wgExtraNamespaces[NS_VISUALEDITOR_TALK] = \'VisualEditor_talk\';\n $wgVisualEditorNamespaces = array( NS_MAIN );\n $wgVisualEditorNamespaces = array();\n $wgVisualEditorNamespaces[] = NS_VISUALEDITOR;\n $wgDefaultUserOptions[\'visualeditor-enable\'] = 1;\n $wgHiddenPrefs[] = \'visualeditor-enable\';\n $wgVisualEditorParsoidURL = \'URL\n\nI installed the current git masters from mediawiki and visualeditor as of today (24 Jan 2013).', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**OS**: Linux\n**Platform**: PC\n**URL**: URL']",TRUE,0,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)." -2208,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)"," - -*** This bug has been marked as a duplicate of bug 44483 ***",1360207511,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gf44zknlabktvyuiobnc","task_subcomment"," - -*** This bug has been marked as a duplicate of bug 44483 ***"," - -*** This bug has been marked as a duplicate of bug 44483 ***",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-21,NA,"['\n\n*** This bug has been marked as a duplicate of bug 44483 ***']",NA,0,"\n\n*** This bug has been marked as a duplicate of bug 44483 ***" -2209,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**mail** wrote: - -http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html - -Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE. -I hope there will be the possibility to have it FALSE in the future :)",1359450666,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_subcomment","**mail** wrote: - -http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html - -Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE. -I hope there will be the possibility to have it FALSE in the future :)","**mail** wrote: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL -Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE. -I hope there will be the possibility to have it FALSE in the future :)",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-22,NA,"[""**mail** wrote:\n\nURL\n\nSolved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE."", 'I hope there will be the possibility to have it FALSE in the future :)']",NA,0,"I hope there will be the possibility to have it FALSE in the future :)" -2209,"Parsoid should support passing on an authenticated user's read right (when MW API supports that)","**mail** wrote: +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page." +534,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","**ignatus31oct** wrote: -Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE. -I hope there will be the possibility to have it FALSE in the future :)",1359450666,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-gf44zknlabktvyuiobnc","task_subcomment","**mail** wrote: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): -http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 -Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE. -I hope there will be the possibility to have it FALSE in the future :)","**mail** wrote: +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. + +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","**ignatus31oct** wrote: + +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): + +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 + +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. + +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: + +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL -Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE. -I hope there will be the possibility to have it FALSE in the future :)",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-22,NA,"[""**mail** wrote:\n\nURL\n\nSolved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE."", 'I hope there will be the possibility to have it FALSE in the future :)']",NA,0,"**mail** wrote:\n\nURL\n\nSolved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE." -2684,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"I\" +534,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","**ignatus31oct** wrote: -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): --------------------------- -**Version**: unspecified -**Severity**: normal",1377700800,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_description","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","**ignatus31oct** wrote: --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): -Example institution page: -URL +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 -Example course page: -URL +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1397705810,NA,"resolved","True","c1",3,"False","False",8,NA,"['VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages.', 'For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"".', '(VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".)', 'Example institution page:\nURL\n\nExample course page:\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages." -2684,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma - -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) - --------------------------- -**Version**: unspecified -**Severity**: normal",1377700800,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_description","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma - -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -URL - -Example course page: -URL - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1397705810,NA,"resolved","True","c1",3,"False","False",8,NA,"['VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages.', 'For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"".', '(VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".)', 'Example institution page:\nURL\n\nExample course page:\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source""." -2684,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma - -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) - --------------------------- -**Version**: unspecified -**Severity**: normal",1377700800,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_description","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma - -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -URL - -Example course page: -URL - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1397705810,NA,"resolved","True","c1",3,"False","False",8,NA,"['VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages.', 'For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"".', '(VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".)', 'Example institution page:\nURL\n\nExample course page:\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"(VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".)" -2684,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma - -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) - --------------------------- -**Version**: unspecified -**Severity**: normal",1377700800,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_description","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma - -Example course page: -http://en.wikipedia.org/wiki/Education_Program:University_of_Oklahoma/History_of_Science_from_Antiquity_to_Newton_(Fall_2013) - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages./n/nFor those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"". (VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".) - -Example institution page: -URL - -Example course page: -URL - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1397705810,NA,"resolved","True","c1",3,"False","False",8,NA,"['VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages.', 'For those with the rights to edit such pages (admins and those with EducationProgram-specific userrights), the Edit button on course pages and institution pages is mislabeled ""Create source"".', '(VE is not enabled in the Education Program: namespace, so it should remain simply ""Edit"".)', 'Example institution page:\nURL\n\nExample course page:\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Example institution page:\nURL\n\nExample course page:\nURL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal" -2685,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: - -P.S. Go to a production wiki and try this in a js console: - -mw.config.get('wgContentNamespaces') - -The results coincide: - -https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L9292-9349 - -I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...",1397734119,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: - -P.S. Go to a production wiki and try this in a js console: - -mw.config.get('wgContentNamespaces') - -The results coincide: - -https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L9292-9349 - -I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...","**andrew.green.df** wrote: - -P.S. Go to a production wiki and try this in a js console: - -mw.config.get('wgContentNamespaces') - -The results coincide: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL -I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['**andrew.green.df** wrote:\n\nP.S.', ""Go to a production wiki and try this in a js console:\n\nmw.config.get('wgContentNamespaces')\n\nThe results coincide:\n\nURL\n\nI lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...""]",NA,0,"**andrew.green.df** wrote:\n\nP.S." -2685,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -P.S. Go to a production wiki and try this in a js console: +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"ve seen........." +534,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","**ignatus31oct** wrote: -mw.config.get('wgContentNamespaces') +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): -The results coincide: +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 -https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L9292-9349 +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...",1397734119,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","**ignatus31oct** wrote: -P.S. Go to a production wiki and try this in a js console: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): -mw.config.get('wgContentNamespaces') +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 -The results coincide: +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L9292-9349 +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: -I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...","**andrew.green.df** wrote: - -P.S. Go to a production wiki and try this in a js console: - -mw.config.get('wgContentNamespaces') - -The results coincide: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): URL -I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['**andrew.green.df** wrote:\n\nP.S.', ""Go to a production wiki and try this in a js console:\n\nmw.config.get('wgContentNamespaces')\n\nThe results coincide:\n\nURL\n\nI lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...""]",NA,0,"Go to a production wiki and try this in a js console:\n\nmw.config.get('wgContentNamespaces')\n\nThe results coincide:\n\nURL\n\nI lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though..." -2686,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",1397732911,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled." +534,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","**ignatus31oct** wrote: -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!","**andrew.green.df** wrote: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['**andrew.green.df** wrote:\n\nAdded a comment on the Gerrit change.', 'tl;dr: Is $wgContentNamespaces getting checked?', ""I don't see how EP_NS could be there, and checking it in js seems to fix the issue."", 'Thanks!']",NA,0,"**andrew.green.df** wrote:\n\nAdded a comment on the Gerrit change." -2686,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",1397732911,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!","**andrew.green.df** wrote: +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",1371221239,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","**ignatus31oct** wrote: -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['**andrew.green.df** wrote:\n\nAdded a comment on the Gerrit change.', 'tl;dr: Is $wgContentNamespaces getting checked?', ""I don't see how EP_NS could be there, and checking it in js seems to fix the issue."", 'Thanks!']",NA,0,"tl;dr: Is $wgContentNamespaces getting checked?" -2686,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",1397732911,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: +http://en.wikipedia.org/w/index.php?title=Russian_grammar&diff=559881732&oldid=558109653 -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!","**andrew.green.df** wrote: +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['**andrew.green.df** wrote:\n\nAdded a comment on the Gerrit change.', 'tl;dr: Is $wgContentNamespaces getting checked?', ""I don't see how EP_NS could be there, and checking it in js seems to fix the issue."", 'Thanks!']",NA,0,"Thanks!" -2686,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........","**ignatus31oct** wrote: -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",1397732911,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: +(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb): -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!","**andrew.green.df** wrote: - -Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['**andrew.green.df** wrote:\n\nAdded a comment on the Gerrit change.', 'tl;dr: Is $wgContentNamespaces getting checked?', ""I don't see how EP_NS could be there, and checking it in js seems to fix the issue."", 'Thanks!']",NA,0,"I don't see how EP_NS could be there, and checking it in js seems to fix the issue." -2687,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Change 125233 merged by jenkins-bot: -Don't change tabs on Education Program pages - -https://gerrit.wikimedia.org/r/125233",1397705933,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","Change 125233 merged by jenkins-bot: -Don't change tabs on Education Program pages - -https://gerrit.wikimedia.org/r/125233","Change 125233 merged by jenkins-bot: -Don't change tabs on Education Program pages - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"[""Change 125233 merged by jenkins-bot:\nDon't change tabs on Education Program pages\n\nGERRIT_URL""]",NA,0,"Change 125233 merged by jenkins-bot:\nDon't change tabs on Education Program pages\n\nGERRIT_URL" -2688,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","(In reply to Andrew Green from comment #9) -> I can look into making the EP extension warn VE through some generic -> mechanism. - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -> BTW, I wouldn't recommend that anyone try to make major changes to the EP -> extension, as the plan is just to rewrite it. - -Understood. - - -> Alex's patch also looks like a fine temporary solution. :) - -Alex's patch is necessarily a horrible hack, but yeah…",1397246077,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","(In reply to Andrew Green from comment #9) -> I can look into making the EP extension warn VE through some generic -> mechanism. - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -> BTW, I wouldn't recommend that anyone try to make major changes to the EP -> extension, as the plan is just to rewrite it. - -Understood. - - -> Alex's patch also looks like a fine temporary solution. :) - -Alex's patch is necessarily a horrible hack, but yeah…","(In reply to Andrew Green from comment #9) -QUOTE -QUOTE - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -QUOTE -QUOTE - -Understood. - - -QUOTE - -Alex's patch is necessarily a horrible hack, but yeah…",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['(In reply to Andrew Green from comment #9)\nQUOTE\nQUOTE\n\nIdeally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely.', ':-)\n\n\nQUOTE\nQUOTE\n\nUnderstood.', ""QUOTE\n\nAlex's patch is necessarily a horrible hack, but yeah…""]",NA,0,"(In reply to Andrew Green from comment #9)\nQUOTE\nQUOTE\n\nIdeally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely." -2688,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","(In reply to Andrew Green from comment #9) -> I can look into making the EP extension warn VE through some generic -> mechanism. - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -> BTW, I wouldn't recommend that anyone try to make major changes to the EP -> extension, as the plan is just to rewrite it. - -Understood. - - -> Alex's patch also looks like a fine temporary solution. :) - -Alex's patch is necessarily a horrible hack, but yeah…",1397246077,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","(In reply to Andrew Green from comment #9) -> I can look into making the EP extension warn VE through some generic -> mechanism. - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -> BTW, I wouldn't recommend that anyone try to make major changes to the EP -> extension, as the plan is just to rewrite it. - -Understood. - - -> Alex's patch also looks like a fine temporary solution. :) - -Alex's patch is necessarily a horrible hack, but yeah…","(In reply to Andrew Green from comment #9) -QUOTE -QUOTE - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -QUOTE -QUOTE - -Understood. - - -QUOTE - -Alex's patch is necessarily a horrible hack, but yeah…",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['(In reply to Andrew Green from comment #9)\nQUOTE\nQUOTE\n\nIdeally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely.', ':-)\n\n\nQUOTE\nQUOTE\n\nUnderstood.', ""QUOTE\n\nAlex's patch is necessarily a horrible hack, but yeah…""]",NA,0,":-)\n\n\nQUOTE\nQUOTE\n\nUnderstood." -2688,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","(In reply to Andrew Green from comment #9) -> I can look into making the EP extension warn VE through some generic -> mechanism. - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -> BTW, I wouldn't recommend that anyone try to make major changes to the EP -> extension, as the plan is just to rewrite it. - -Understood. - - -> Alex's patch also looks like a fine temporary solution. :) - -Alex's patch is necessarily a horrible hack, but yeah…",1397246077,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","(In reply to Andrew Green from comment #9) -> I can look into making the EP extension warn VE through some generic -> mechanism. - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -> BTW, I wouldn't recommend that anyone try to make major changes to the EP -> extension, as the plan is just to rewrite it. - -Understood. - - -> Alex's patch also looks like a fine temporary solution. :) - -Alex's patch is necessarily a horrible hack, but yeah…","(In reply to Andrew Green from comment #9) -QUOTE -QUOTE - -Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-) - - -QUOTE -QUOTE - -Understood. - - -QUOTE - -Alex's patch is necessarily a horrible hack, but yeah…",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['(In reply to Andrew Green from comment #9)\nQUOTE\nQUOTE\n\nIdeally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely.', ':-)\n\n\nQUOTE\nQUOTE\n\nUnderstood.', ""QUOTE\n\nAlex's patch is necessarily a horrible hack, but yeah…""]",NA,0,"QUOTE\n\nAlex's patch is necessarily a horrible hack, but yeah…" -2689,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",1397245474,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['**andrew.green.df** wrote:\n\nI can look into making the EP extension warn VE through some generic mechanism.', ""The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes."", ""BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it."", 'The issues Krinkle mentions are certainly valid.', ""Alex's patch also looks like a fine temporary solution."", ':)']",NA,0,"**andrew.green.df** wrote:\n\nI can look into making the EP extension warn VE through some generic mechanism." -2689,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",1397245474,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['**andrew.green.df** wrote:\n\nI can look into making the EP extension warn VE through some generic mechanism.', ""The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes."", ""BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it."", 'The issues Krinkle mentions are certainly valid.', ""Alex's patch also looks like a fine temporary solution."", ':)']",NA,0,"The issues Krinkle mentions are certainly valid." -2689,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",1397245474,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['**andrew.green.df** wrote:\n\nI can look into making the EP extension warn VE through some generic mechanism.', ""The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes."", ""BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it."", 'The issues Krinkle mentions are certainly valid.', ""Alex's patch also looks like a fine temporary solution."", ':)']",NA,0,":)" -2689,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",1397245474,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['**andrew.green.df** wrote:\n\nI can look into making the EP extension warn VE through some generic mechanism.', ""The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes."", ""BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it."", 'The issues Krinkle mentions are certainly valid.', ""Alex's patch also looks like a fine temporary solution."", ':)']",NA,0,"The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes." -2689,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",1397245474,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['**andrew.green.df** wrote:\n\nI can look into making the EP extension warn VE through some generic mechanism.', ""The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes."", ""BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it."", 'The issues Krinkle mentions are certainly valid.', ""Alex's patch also looks like a fine temporary solution."", ':)']",NA,0,"BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it." -2689,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",1397245474,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)","**andrew.green.df** wrote: - -I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes. - -BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it. - -The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['**andrew.green.df** wrote:\n\nI can look into making the EP extension warn VE through some generic mechanism.', ""The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes."", ""BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it."", 'The issues Krinkle mentions are certainly valid.', ""Alex's patch also looks like a fine temporary solution."", ':)']",NA,0,"Alex's patch also looks like a fine temporary solution." -2690,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","(In reply to Krinkle from comment #7) -> I'd say EP should either let us know how to generically detect it without -> being EP specific, or it should implement support to at least do one thing -> right. Possibly we could do the latter ourselves (maybe Alex is interested -> in patching EP). - -I don't really think this bug is important enough to VE to justify making big changes to how another extension works...",1397243067,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","(In reply to Krinkle from comment #7) -> I'd say EP should either let us know how to generically detect it without -> being EP specific, or it should implement support to at least do one thing -> right. Possibly we could do the latter ourselves (maybe Alex is interested -> in patching EP). - -I don't really think this bug is important enough to VE to justify making big changes to how another extension works...","(In reply to Krinkle from comment #7) -QUOTE -QUOTE -QUOTE -QUOTE - -I don't really think this bug is important enough to VE to justify making big changes to how another extension works...",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"[""(In reply to Krinkle from comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't really think this bug is important enough to VE to justify making big changes to how another extension works...""]",NA,0,"(In reply to Krinkle from comment #7)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI don't really think this bug is important enough to VE to justify making big changes to how another extension works..." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"Not one of them is being used by EP right now." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"* Generally this is something we have Special pages for." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"), it should be a Special page." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"Or at least a custom namespace with a negative namespace id." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"Right now they take over move, delete, edit and view." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails)." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"For example ""View history"" (action=history) is quite useless right now." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"Not to mention API actions, none of those are working as expected." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"3) Existence check impossible." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"Possibly we could do the latter ourselves (maybe Alex is interested in patching EP)." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"2) It doesn't scale." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"And action=edit doesn't work as expected." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"Because they aren't actually wiki pages with page and revision ids, existence check isn't possible." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"ContentModel can't be overridden because it doesn't use wikipage content." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them." -2691,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",1397241093,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage. - -Not one of them is being used by EP right now. - -* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page). - -* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id. - -* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because: - 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=). - 2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected. - 3) Existence check impossible. Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases. - -There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them. - -I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.', 'Not one of them is being used by EP right now.', ""* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page)."", '* Generally this is something we have Special pages for.', 'If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.', '), it should be a Special page.', 'Or at least a custom namespace with a negative namespace id.', ""* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage."", ""So inherently this is going to cause trouble because:\n 1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=)."", ""2) It doesn't scale."", 'Right now they take over move, delete, edit and view.', 'But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails).', 'For example ""View history"" (action=history) is quite useless right now.', ""And action=edit doesn't work as expected."", 'Not to mention API actions, none of those are working as expected.', '3) Existence check impossible.', ""Because they aren't actually wiki pages with page and revision ids, existence check isn't possible."", ""ContentModel can't be overridden because it doesn't use wikipage content."", 'All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.', ""There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them."", ""I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right."", 'Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).']",NA,0,"I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right." -2692,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Change 125233 had a related patch set uploaded by Alex Monk: -Only make tab changes on articles - -https://gerrit.wikimedia.org/r/125233",1397151063,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","Change 125233 had a related patch set uploaded by Alex Monk: -Only make tab changes on articles - -https://gerrit.wikimedia.org/r/125233","Change 125233 had a related patch set uploaded by Alex Monk: -Only make tab changes on articles - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['Change 125233 had a related patch set uploaded by Alex Monk:\nOnly make tab changes on articles\n\nGERRIT_URL']",NA,0,"Change 125233 had a related patch set uploaded by Alex Monk:\nOnly make tab changes on articles\n\nGERRIT_URL" -2693,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).",1396995419,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).","I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"[""I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).""]",NA,0,"I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything)." -2694,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?",1396986708,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?","Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,40,NA,"['Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?']",NA,0,"Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?" -2695,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)",1396986438,"PHID-USER-brn4v5ta45bnw4f5as3h","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)","Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it.', ':)']",NA,0,"Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it." -2695,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)",1396986438,"PHID-USER-brn4v5ta45bnw4f5as3h","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)","Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,40,NA,"['Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it.', ':)']",NA,0,":)" -2696,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","*** Bug 56844 has been marked as a duplicate of this bug. ***",1384096303,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","*** Bug 56844 has been marked as a duplicate of this bug. ***","*** Bug 56844 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,18,NA,"['*** Bug 56844 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 56844 has been marked as a duplicate of this bug." -2696,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","*** Bug 56844 has been marked as a duplicate of this bug. ***",1384096303,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","*** Bug 56844 has been marked as a duplicate of this bug. ***","*** Bug 56844 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,18,NA,"['*** Bug 56844 has been marked as a duplicate of this bug.', '***']",NA,0,"***" -2697,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","@James: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.",1378409168,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","@James: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.","SCREEN_NAME: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['SCREEN_NAME: Any chance of getting this fixed soon?', 'Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.']",NA,0,"SCREEN_NAME: Any chance of getting this fixed soon?" -2697,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","@James: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.",1378409168,"PHID-USER-nyv6rqxnzdy3oe323a3d","PHID-TASK-4lk6qpiuan7kbk6fch54","task_subcomment","@James: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.","SCREEN_NAME: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,9,NA,"['SCREEN_NAME: Any chance of getting this fixed soon?', 'Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.']",NA,0,"Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse." -2831,"VisualEditor: Inspector fails to render correctly for embedded buttons","Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1376488380,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-4hkjv2ath5m5txk2nfy2","task_description","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1376511662,NA,"resolved","True","c1",3,"True","False",6,NA,"['VisualEditor: Inspector fails to render correctly for embedded buttons.', ""Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g."", 'Math) we need it to work in block mode as well.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Inspector fails to render correctly for embedded buttons." -2831,"VisualEditor: Inspector fails to render correctly for embedded buttons","Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1376488380,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-4hkjv2ath5m5txk2nfy2","task_description","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1376511662,NA,"resolved","True","c1",3,"True","False",6,NA,"['VisualEditor: Inspector fails to render correctly for embedded buttons.', ""Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g."", 'Math) we need it to work in block mode as well.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Math) we need it to work in block mode as well." -2831,"VisualEditor: Inspector fails to render correctly for embedded buttons","Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1376488380,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-4hkjv2ath5m5txk2nfy2","task_description","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1376511662,NA,"resolved","True","c1",3,"True","False",6,NA,"['VisualEditor: Inspector fails to render correctly for embedded buttons.', ""Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g."", 'Math) we need it to work in block mode as well.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" -2831,"VisualEditor: Inspector fails to render correctly for embedded buttons","Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal",1376488380,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-4hkjv2ath5m5txk2nfy2","task_description","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Inspector fails to render correctly for embedded buttons./n/nHasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g. Math) we need it to work in block mode as well. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1376511662,NA,"resolved","True","c1",3,"True","False",6,NA,"['VisualEditor: Inspector fails to render correctly for embedded buttons.', ""Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g."", 'Math) we need it to work in block mode as well.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Hasn't been an issue until now as we've only used inspectors on text, but now we have inspectors for MW extensions (e.g." -2832,"VisualEditor: Inspector fails to render correctly for embedded buttons","Change 79055 merged by jenkins-bot: -Fix rendering of inspector for embedded buttons - -https://gerrit.wikimedia.org/r/79055",1376509523,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-4hkjv2ath5m5txk2nfy2","task_subcomment","Change 79055 merged by jenkins-bot: -Fix rendering of inspector for embedded buttons - -https://gerrit.wikimedia.org/r/79055","Change 79055 merged by jenkins-bot: -Fix rendering of inspector for embedded buttons - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,6,NA,"['Change 79055 merged by jenkins-bot:\nFix rendering of inspector for embedded buttons\n\nGERRIT_URL']",NA,0,"Change 79055 merged by jenkins-bot:\nFix rendering of inspector for embedded buttons\n\nGERRIT_URL" -2833,"VisualEditor: Inspector fails to render correctly for embedded buttons","Change 79055 had a related patch set uploaded by Esanders: -Fix rendering of inspector for embedded buttons - -https://gerrit.wikimedia.org/r/79055",1376491490,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-4hkjv2ath5m5txk2nfy2","task_subcomment","Change 79055 had a related patch set uploaded by Esanders: -Fix rendering of inspector for embedded buttons - -https://gerrit.wikimedia.org/r/79055","Change 79055 had a related patch set uploaded by Esanders: -Fix rendering of inspector for embedded buttons - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,6,NA,"['Change 79055 had a related patch set uploaded by Esanders:\nFix rendering of inspector for embedded buttons\n\nGERRIT_URL']",NA,0,"Change 79055 had a related patch set uploaded by Esanders:\nFix rendering of inspector for embedded buttons\n\nGERRIT_URL" -3265,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","If you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal",1374604560,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-jxtza5wxkt3lvc2yga75","task_description","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under URL you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1374779912,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog.', 'If you look at page settings under URL you\'ll see the category ""Wikipedia"".', ""This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog." -3265,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","If you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal",1374604560,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-jxtza5wxkt3lvc2yga75","task_description","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under URL you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1374779912,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog.', 'If you look at page settings under URL you\'ll see the category ""Wikipedia"".', ""This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"If you look at page settings under URL you\" -3265,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","If you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal",1374604560,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-jxtza5wxkt3lvc2yga75","task_description","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under URL you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1374779912,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog.', 'If you look at page settings under URL you\'ll see the category ""Wikipedia"".', ""This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,", ""This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn" -3265,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","If you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal",1374604560,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-jxtza5wxkt3lvc2yga75","task_description","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under URL you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1374779912,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog.', 'If you look at page settings under URL you\'ll see the category ""Wikipedia"".', ""This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" -3265,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","If you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal",1374604560,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-jxtza5wxkt3lvc2yga75","task_description","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under https://sv.wikipedia.org/wiki/Violin?veaction=edit you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog./n/nIf you look at page settings under URL you'll see the category ""Wikipedia"". This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1374779912,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog.', 'If you look at page settings under URL you\'ll see the category ""Wikipedia"".', ""This is actually Kategori:Wikipedia:Basartiklar if you look at the page source; it seems the VE isn't including category elements that are preceded by a colon."", '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Wikipedia" -3266,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","Now fixed in master.",1374779912,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jxtza5wxkt3lvc2yga75","task_subcomment","Now fixed in master.","Now fixed in master.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"['Now fixed in master.']",NA,0,"Now fixed in master." -3267,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","Change 75859 merged by jenkins-bot: -Parse category names correctly - -https://gerrit.wikimedia.org/r/75859",1374776211,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jxtza5wxkt3lvc2yga75","task_subcomment","Change 75859 merged by jenkins-bot: -Parse category names correctly - -https://gerrit.wikimedia.org/r/75859","Change 75859 merged by jenkins-bot: -Parse category names correctly - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Change 75859 merged by jenkins-bot:\nParse category names correctly\n\nGERRIT_URL']",NA,0,"Change 75859 merged by jenkins-bot:\nParse category names correctly\n\nGERRIT_URL" -3268,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","Change 75859 had a related patch set uploaded by Esanders: -Parse category names correctly - -https://gerrit.wikimedia.org/r/75859",1374756861,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jxtza5wxkt3lvc2yga75","task_subcomment","Change 75859 had a related patch set uploaded by Esanders: -Parse category names correctly - -https://gerrit.wikimedia.org/r/75859","Change 75859 had a related patch set uploaded by Esanders: -Parse category names correctly - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Change 75859 had a related patch set uploaded by Esanders:\nParse category names correctly\n\nGERRIT_URL']",NA,0,"Change 75859 had a related patch set uploaded by Esanders:\nParse category names correctly\n\nGERRIT_URL" -3269,"VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog","This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]].",1374683040,"PHID-USER-uf3buojo4ceizjywvyn5","PHID-TASK-jxtza5wxkt3lvc2yga75","task_subcomment","This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]].","This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]].",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]].']",NA,0,"This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]]." -3795,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=60358",1372947300,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_description","VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters./n/nTemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=60358","VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters./n/nTemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -URL","High",80,1410982793,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters.', ""TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters." -3795,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=60358",1372947300,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_description","VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters./n/nTemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=60358","VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters./n/nTemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -URL","High",80,1410982793,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters.', ""TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL" -3795,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=60358",1372947300,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_description","VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters./n/nTemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -https://bugzilla.wikimedia.org/show_bug.cgi?id=60358","VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters./n/nTemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required. - --------------------------- -**Version**: unspecified -**Severity**: normal -**See Also**: -URL","High",80,1410982793,NA,"resolved","True","c1",3,"True","False",0,NA,"['VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters.', ""TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required."", '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL']",FALSE,0,"TemplateData makes it possible to have 'required' parameters, but not using these parameters in the Template editor, does not alert you of the fact that these parameters are required." -3796,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Verified the fix in production",1411682658,"PHID-USER-24djtv3gj5gua2y6u2g5","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Verified the fix in production","Verified the fix in production",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,64,NA,"['Verified the fix in production']",NA,0,"Verified the fix in production" -3797,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Verified the fix in test2",1411081594,"PHID-USER-24djtv3gj5gua2y6u2g5","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Verified the fix in test2","Verified the fix in test2",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,63,NA,"['Verified the fix in test2']",NA,0,"Verified the fix in test2" -3798,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Verified the fix to show confirmation dialog when trying to insert/edit a template with one or more missing required parameters",1410991738,"PHID-USER-24djtv3gj5gua2y6u2g5","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Verified the fix to show confirmation dialog when trying to insert/edit a template with one or more missing required parameters","Verified the fix to show confirmation dialog when trying to insert/edit a template with one or more missing required parameters",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,63,NA,"['Verified the fix to show confirmation dialog when trying to insert/edit a template with one or more missing required parameters']",NA,0,"Verified the fix to show confirmation dialog when trying to insert/edit a template with one or more missing required parameters" -3799,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","There are still some remaining improvements (as always), but the thrust of this bug is now done.",1410982793,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","There are still some remaining improvements (as always), but the thrust of this bug is now done.","There are still some remaining improvements (as always), but the thrust of this bug is now done.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,63,NA,"['There are still some remaining improvements (as always), but the thrust of this bug is now done.']",NA,0,"There are still some remaining improvements (as always), but the thrust of this bug is now done." -3800,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Change 156559 merged by jenkins-bot: -Get confirmation when trying to insert/edit template/citation with required parameters missing - -https://gerrit.wikimedia.org/r/156559",1410982430,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Change 156559 merged by jenkins-bot: -Get confirmation when trying to insert/edit template/citation with required parameters missing - -https://gerrit.wikimedia.org/r/156559","Change 156559 merged by jenkins-bot: -Get confirmation when trying to insert/edit template/citation with required parameters missing - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,63,NA,"['Change 156559 merged by jenkins-bot:\nGet confirmation when trying to insert/edit template/citation with required parameters missing\n\nGERRIT_URL']",NA,0,"Change 156559 merged by jenkins-bot:\nGet confirmation when trying to insert/edit template/citation with required parameters missing\n\nGERRIT_URL" -3801,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Change 156559 had a related patch set uploaded by Alex Monk: -Get confirmation when trying to insert template with required parameters missing - -https://gerrit.wikimedia.org/r/156559",1409154385,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Change 156559 had a related patch set uploaded by Alex Monk: -Get confirmation when trying to insert template with required parameters missing - -https://gerrit.wikimedia.org/r/156559","Change 156559 had a related patch set uploaded by Alex Monk: -Get confirmation when trying to insert template with required parameters missing - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,60,NA,"['Change 156559 had a related patch set uploaded by Alex Monk:\nGet confirmation when trying to insert template with required parameters missing\n\nGERRIT_URL']",NA,0,"Change 156559 had a related patch set uploaded by Alex Monk:\nGet confirmation when trying to insert template with required parameters missing\n\nGERRIT_URL" -3802,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","We're also going to require the user to confirm when they try to insert a template with required parameters missing.",1409154296,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","We're also going to require the user to confirm when they try to insert a template with required parameters missing.","We're also going to require the user to confirm when they try to insert a template with required parameters missing.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,60,NA,"[""We're also going to require the user to confirm when they try to insert a template with required parameters missing.""]",NA,0,"We're also going to require the user to confirm when they try to insert a template with required parameters missing." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"I just used the Cite news template in VE, via the mini-editor." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"That template has a number of ""required"" parameters." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"I also tested the Infobox person template, which uses the regular Template dialog." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"That template has one required parameter, ""Name""." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"And the inserted template did *not* have a value for the one required parameter." -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"So not only are ""required"" parameters not enforced by VE, but VE doesn\" -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,", ""That is quite unhelpful; it" -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"t one of the goals of the VE team.)"", " -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,", '(I note, in passing, that the marking of " -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0," fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', " -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"One or more required parameters is missing" -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"return to dialog" -3803,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",1408766440,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.","I just used the Cite news template in VE, via the mini-editor. That template has a number of ""required"" parameters. I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page. - -I also tested the Infobox person template, which uses the regular Template dialog. That template has one required parameter, ""Name"". I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed. And the inserted template did *not* have a value for the one required parameter. - -So not only are ""required"" parameters not enforced by VE, but VE doesn't even *warn* the user that one or more required parameters are missing. That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor. - -(I note, in passing, that the marking of ""required"" fields is, let's say, *subtle* - an uncolored asterisk that doesn't have a tooltip. I hope that subtlety isn't one of the goals of the VE team.) - -At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"". Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog. - -And NO, Bug 60358 does not address *anything* about the templates creation process (as described above). Bug 60358 is about *editing* an existing template, which is a different thing.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['I just used the Cite news template in VE, via the mini-editor.', 'That template has a number of ""required"" parameters.', 'I added just a url (a non-required field), clicked ""Insert citation"", and the dialog closed, posting the citation to the main page.', 'I also tested the Infobox person template, which uses the regular Template dialog.', 'That template has one required parameter, ""Name"".', 'I ignored that parameter, added another one, filled in the second one, and clicked ""Insert template""; the dialog box closed.', 'And the inserted template did *not* have a value for the one required parameter.', 'So not only are ""required"" parameters not enforced by VE, but VE doesn\'t even *warn* the user that one or more required parameters are missing.', ""That is quite unhelpful; it's a missed opportunity for VE to be *better* than the wikitext editor."", '(I note, in passing, that the marking of ""required"" fields is, let\'s say, *subtle* - an uncolored asterisk that doesn\'t have a tooltip.', ""I hope that subtlety isn't one of the goals of the VE team.)"", 'At minimum, VE should display a warning (pop-up box) that says ""One or more required parameters is missing"".', 'Then the user could choose either to click on ""return to dialog"" or click on ""insert citation""; the latter would finish the dialog.', 'And NO, Bug 60358 does not address *anything* about the templates creation process (as described above).', 'Bug 60358 is about *editing* an existing template, which is a different thing.']",NA,0,"insert citation" -3804,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to Alex Monk from comment #14) -> Is there anything left here to do that isn't bug 60358? - -I believe that that will complete this.",1408762442,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to Alex Monk from comment #14) -> Is there anything left here to do that isn't bug 60358? - -I believe that that will complete this.","(In reply to Alex Monk from comment #14) -QUOTE - -I believe that that will complete this.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,59,NA,"['(In reply to Alex Monk from comment #14)\nQUOTE\n\nI believe that that will complete this.']",NA,0,"(In reply to Alex Monk from comment #14)\nQUOTE\n\nI believe that that will complete this." -3805,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Is there anything left here to do that isn't bug 60358?",1408757255,"PHID-USER-x7ti5ksby4ubsabntlxa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Is there anything left here to do that isn't bug 60358?","Is there anything left here to do that isn't bug 60358?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,59,NA,"[""Is there anything left here to do that isn't bug 60358?""]",NA,0,"Is there anything left here to do that isn't bug 60358?" -3806,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",1386641485,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,23,NA,"[""I haven't tested required/optional fields in depth, but some casual tests suggest that currently\n\n* Required and optional parameters are presented differently."", 'The required can be seen in a left column, while the optional are in the ""body"".', 'Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?', '), but you get the idea after filling the first templates.', ""* Required field aren't still enforced, nor there is any warning when they are left empty."", 'My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...']",NA,0,"The required can be seen in a left column, while the optional are in the ""body""." -3806,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",1386641485,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,23,NA,"[""I haven't tested required/optional fields in depth, but some casual tests suggest that currently\n\n* Required and optional parameters are presented differently."", 'The required can be seen in a left column, while the optional are in the ""body"".', 'Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?', '), but you get the idea after filling the first templates.', ""* Required field aren't still enforced, nor there is any warning when they are left empty."", 'My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...']",NA,0,"Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?" -3806,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",1386641485,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,23,NA,"[""I haven't tested required/optional fields in depth, but some casual tests suggest that currently\n\n* Required and optional parameters are presented differently."", 'The required can be seen in a left column, while the optional are in the ""body"".', 'Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?', '), but you get the idea after filling the first templates.', ""* Required field aren't still enforced, nor there is any warning when they are left empty."", 'My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...']",NA,0,"), but you get the idea after filling the first templates." -3806,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",1386641485,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,23,NA,"[""I haven't tested required/optional fields in depth, but some casual tests suggest that currently\n\n* Required and optional parameters are presented differently."", 'The required can be seen in a left column, while the optional are in the ""body"".', 'Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?', '), but you get the idea after filling the first templates.', ""* Required field aren't still enforced, nor there is any warning when they are left empty."", 'My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...']",NA,0,"My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required..." -3806,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",1386641485,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,23,NA,"[""I haven't tested required/optional fields in depth, but some casual tests suggest that currently\n\n* Required and optional parameters are presented differently."", 'The required can be seen in a left column, while the optional are in the ""body"".', 'Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?', '), but you get the idea after filling the first templates.', ""* Required field aren't still enforced, nor there is any warning when they are left empty."", 'My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...']",NA,0,"I haven't tested required/optional fields in depth, but some casual tests suggest that currently\n\n* Required and optional parameters are presented differently." -3806,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",1386641485,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...","I haven't tested required/optional fields in depth, but some casual tests suggest that currently - -* Required and optional parameters are presented differently. The required can be seen in a left column, while the optional are in the ""body"". Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?), but you get the idea after filling the first templates. - -* Required field aren't still enforced, nor there is any warning when they are left empty. - -My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,23,NA,"[""I haven't tested required/optional fields in depth, but some casual tests suggest that currently\n\n* Required and optional parameters are presented differently."", 'The required can be seen in a left column, while the optional are in the ""body"".', 'Not the most self-evident UX if you ask me (why not adding labels ""Required"" / ""Optional""?', '), but you get the idea after filling the first templates.', ""* Required field aren't still enforced, nor there is any warning when they are left empty."", 'My expectation as an editor is that a field marked as ""required"" in the documentation it is actually required...']",NA,0,"* Required field aren't still enforced, nor there is any warning when they are left empty." -3807,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",1374454542,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters."", 'The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters.', 'It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that\'s not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"".', 'As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.']",NA,0,"The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters." -3807,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",1374454542,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters."", 'The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters.', 'It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that\'s not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"".', 'As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.']",NA,0,"It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that\" -3807,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",1374454542,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters."", 'The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters.', 'It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that\'s not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"".', 'As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.']",NA,0,"I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters." -3807,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",1374454542,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters."", 'The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters.', 'It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that\'s not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"".', 'As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.']",NA,0,"required" -3807,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",1374454542,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters."", 'The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters.', 'It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that\'s not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"".', 'As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.']",NA,0,"recommended" -3807,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",1374454542,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.","I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters. The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters. - -It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that's not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"". - -As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""I don't see why Wikipedia communities can't be trusted to decide what is *mandatory* and what is not, for template parameters."", 'The communities are, after all, the ones who will live with the consequences of over-specifying or under-specifying such parameters.', 'It seems a bit paternalistic for the WMF to tell these communities that whether or not they want the software to help ensure that ""required"" parameters are non-blank, that\'s not going to happen - that WMF considers anything ""required"" to actually be just ""recommended"".', 'As an absolute minimum, VE should issue a warning when a ""required"" parameter is left blank.']",NA,0,"required" -3808,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Not enforcing mandatory params is a bug in either design or implementation.",1374447401,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Not enforcing mandatory params is a bug in either design or implementation.","Not enforcing mandatory params is a bug in either design or implementation.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Not enforcing mandatory params is a bug in either design or implementation.']",NA,0,"Not enforcing mandatory params is a bug in either design or implementation." -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,"Should there be ""not recommended"" parameters (I\" -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,", ""More generally, I don" -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,"t need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", " -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,"for experts only" -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,"not recommended" -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,"required" -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,"suggested" -3809,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",1374079148,"PHID-USER-hirrhium5ibrtof34lwa","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.","Should there be ""not recommended"" parameters (I'd suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?) should be marked as such by a label, when listed as parameters that *could* be added. - -More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates. We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis. - -In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Should there be ""not recommended"" parameters (I\'d suggest something like ""for experts only"" as a label; if something is ""not recommended"", why have it at all?)', 'should be marked as such by a label, when listed as parameters that *could* be added.', ""More generally, I don't think we need to worry much about really complex templates, if (as suggested elsewhere) the template dialog box includes a link to the documentation page for such templates."", ""We don't need to worry much because only editors who are really interested - and motivated to understand the template - are likely to go beyond the parameters that are required and suggested, with the possible exception of editors who (idiosyncratically) use a less common parameter on a regular basis."", 'In short, a ""required"" and a ""suggested"" list (AND enforcing that the ""required"" list be filled in) would be a huge win for the occasional user of templates.']",NA,0,"required" -3810,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Indeed, I gave up doing this for the Portuguese version for now: -https://pt.wikipedia.org/wiki/Template:Info/Taxonomia?uselang=en",1373922302,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Indeed, I gave up doing this for the Portuguese version for now: -https://pt.wikipedia.org/wiki/Template:Info/Taxonomia?uselang=en","Indeed, I gave up doing this for the Portuguese version for now: -URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Indeed, I gave up doing this for the Portuguese version for now:\nURL']",NA,0,"Indeed, I gave up doing this for the Portuguese version for now:\nURL" -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional""." -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"I\" -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"t want the user to enter, the color parameter in the Taxobox is such a case." -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented." -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"BTW Taxobox URL is a nice torture test." -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"It has over 100 parameter, most will not need to be used, but there will be an article using each." -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested""." -3811,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",1373921757,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","This topic came up in http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Duplicate_parameters_in_a_template -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox http://en.wikipedia.org/wiki/Taxobox is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".","This topic came up in URL -and John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"". - -I'd possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don't want the user to enter, the color parameter in the Taxobox is such a case. Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented. - -BTW Taxobox URL is a nice torture test. It has over 100 parameter, most will not need to be used, but there will be an article using each. Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['This topic came up in URL\nand John Broughton came up with the idea that you really want more types of status: ""required"" - must be set, ""suggested"" - appears automatically on the lhs, and ""optional"".', 'I\'d possibly add a ""not recommended"" for parameters which are there to cover corner cases but you really don\'t want the user to enter, the color parameter in the Taxobox is such a case.', 'Its only useful for subtemplate calling taxobox and should almost never be used in an article, but it needs to be documented.', 'BTW Taxobox URL is a nice torture test.', 'It has over 100 parameter, most will not need to be used, but there will be an article using each.', 'Perhaphs 10 of these are the most likely to be used which could be marked as ""suggested"".']",NA,0,"not recommended" -3812,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","English Wikipedian Joe Decker recommends indicating required parameters perhaps with the standard red asterisk.",1373565271,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","English Wikipedian Joe Decker recommends indicating required parameters perhaps with the standard red asterisk.","English Wikipedian Joe Decker recommends indicating required parameters perhaps with the standard red asterisk.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['English Wikipedian Joe Decker recommends indicating required parameters perhaps with the standard red asterisk.']",NA,0,"English Wikipedian Joe Decker recommends indicating required parameters perhaps with the standard red asterisk." -3813,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%",1373565194,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%","%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['%%%*** Bug 51186 has been marked as a duplicate of this bug.', '***%%%']",NA,0,"%%%*** Bug 51186 has been marked as a duplicate of this bug." -3813,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%",1373565194,"PHID-USER-joqqkabmjmvxeucx4ni2","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%","%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['%%%*** Bug 51186 has been marked as a duplicate of this bug.', '***%%%']",NA,0,"***%%%" -3814,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Change 73136 merged by jenkins-bot: -Auto-add required params for user added templates - -https://gerrit.wikimedia.org/r/73136",1373560433,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Change 73136 merged by jenkins-bot: -Auto-add required params for user added templates - -https://gerrit.wikimedia.org/r/73136","Change 73136 merged by jenkins-bot: -Auto-add required params for user added templates - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Change 73136 merged by jenkins-bot:\nAuto-add required params for user added templates\n\nGERRIT_URL']",NA,0,"Change 73136 merged by jenkins-bot:\nAuto-add required params for user added templates\n\nGERRIT_URL" -3815,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Leaving at ""recommend"" for now since we can't fully ensure that requiring all parameters is consistently the desired behavior.",1373507848,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Leaving at ""recommend"" for now since we can't fully ensure that requiring all parameters is consistently the desired behavior.","Leaving at ""recommend"" for now since we can't fully ensure that requiring all parameters is consistently the desired behavior.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Leaving at ""recommend"" for now since we can\'t fully ensure that requiring all parameters is consistently the desired behavior.']",NA,0,"Leaving at ""recommend"" for now since we can\" -3816,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",1373503365,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)","(In reply to comment #2) -QUOTE -QUOTE -QUOTE -QUOTE - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence.', 'Not sure if we should do that (or let users do what they want).', 'Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template.', '(Put them at the top?', 'Highlight them?', 'Icon?', '…)']",NA,0,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence." -3816,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",1373503365,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)","(In reply to comment #2) -QUOTE -QUOTE -QUOTE -QUOTE - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence.', 'Not sure if we should do that (or let users do what they want).', 'Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template.', '(Put them at the top?', 'Highlight them?', 'Icon?', '…)']",NA,0,"Not sure if we should do that (or let users do what they want)." -3816,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",1373503365,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)","(In reply to comment #2) -QUOTE -QUOTE -QUOTE -QUOTE - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence.', 'Not sure if we should do that (or let users do what they want).', 'Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template.', '(Put them at the top?', 'Highlight them?', 'Icon?', '…)']",NA,0,"Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template." -3816,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",1373503365,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)","(In reply to comment #2) -QUOTE -QUOTE -QUOTE -QUOTE - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence.', 'Not sure if we should do that (or let users do what they want).', 'Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template.', '(Put them at the top?', 'Highlight them?', 'Icon?', '…)']",NA,0,"(Put them at the top?" -3816,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",1373503365,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)","(In reply to comment #2) -QUOTE -QUOTE -QUOTE -QUOTE - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence.', 'Not sure if we should do that (or let users do what they want).', 'Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template.', '(Put them at the top?', 'Highlight them?', 'Icon?', '…)']",NA,0,"Highlight them?" -3816,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",1373503365,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)","(In reply to comment #2) -QUOTE -QUOTE -QUOTE -QUOTE - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence.', 'Not sure if we should do that (or let users do what they want).', 'Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template.', '(Put them at the top?', 'Highlight them?', 'Icon?', '…)']",NA,0,"Icon?" -3816,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",1373503365,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","(In reply to comment #2) -> Change 73136 had a related patch set uploaded by Jforrester: -> Auto-add required params for user added templates -> -> https://gerrit.wikimedia.org/r/73136 - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)","(In reply to comment #2) -QUOTE -QUOTE -QUOTE -QUOTE - -This just adds the parameters, not ""enforcing"" their presence. Not sure if we should do that (or let users do what they want). - -Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template. (Put them at the top? Highlight them? Icon? …)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,1,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis just adds the parameters, not ""enforcing"" their presence.', 'Not sure if we should do that (or let users do what they want).', 'Another improvement under this bug will be to indicate mandatory ones in the list of available parameters on the template.', '(Put them at the top?', 'Highlight them?', 'Icon?', '…)']",NA,0,"…)" -3817,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Change 73136 had a related patch set uploaded by Jforrester: -Auto-add required params for user added templates - -https://gerrit.wikimedia.org/r/73136",1373503236,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Change 73136 had a related patch set uploaded by Jforrester: -Auto-add required params for user added templates - -https://gerrit.wikimedia.org/r/73136","Change 73136 had a related patch set uploaded by Jforrester: -Auto-add required params for user added templates - -GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Change 73136 had a related patch set uploaded by Jforrester:\nAuto-add required params for user added templates\n\nGERRIT_URL']",NA,0,"Change 73136 had a related patch set uploaded by Jforrester:\nAuto-add required params for user added templates\n\nGERRIT_URL" -3818,"VisualEditor: Transclusion dialog should recommend TemplateData-hinted mandatory parameters","Indeed, this seems like a low hanging fruit improvement - when inserting a new template, having all the required fields immediately be ready for use would significantly speed up template completion.",1373354062,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-ob2d5ffvdmtamrwpb4u7","task_subcomment","Indeed, this seems like a low hanging fruit improvement - when inserting a new template, having all the required fields immediately be ready for use would significantly speed up template completion.","Indeed, this seems like a low hanging fruit improvement - when inserting a new template, having all the required fields immediately be ready for use would significantly speed up template completion.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,1,NA,"['Indeed, this seems like a low hanging fruit improvement - when inserting a new template, having all the required fields immediately be ready for use would significantly speed up template completion.']",NA,0,"Indeed, this seems like a low hanging fruit improvement - when inserting a new template, having all the required fields immediately be ready for use would significantly speed up template completion." -5445,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement",1366932300,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_description","VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page./n/nEditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement","VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page./n/nEditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement","High",80,1369409008,NA,"resolved","True","c1",1,"True","False",-10,NA,"['VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page.', 'EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,1,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page." -5445,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement",1366932300,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_description","VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page./n/nEditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement","VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page./n/nEditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement","High",80,1369409008,NA,"resolved","True","c1",1,"True","False",-10,NA,"['VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page.', 'EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,1,"EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality." -5445,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement",1366932300,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_description","VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page./n/nEditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement","VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page./n/nEditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality. - --------------------------- -**Version**: unspecified -**Severity**: enhancement","High",80,1369409008,NA,"resolved","True","c1",1,"True","False",-10,NA,"['VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page.', 'EditPage.php has a prominent notice that users are editing an oldid page; VE should have something similar, probably in the ""notices"" functionality.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",TRUE,1,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement" -5446,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","Merged and will go out with wmf5 on 27 May.",1369409008,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","Merged and will go out with wmf5 on 27 May.","Merged and will go out with wmf5 on 27 May.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['Merged and will go out with wmf5 on 27 May.']",NA,1,"Merged and will go out with wmf5 on 27 May." -5447,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","Related URL: https://gerrit.wikimedia.org/r/65291 (Gerrit Change I216cdd68014173aa65cad42ddd3d870334be9ead)",1369406998,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/65291 (Gerrit Change I216cdd68014173aa65cad42ddd3d870334be9ead)","Related URL: GERRIT_URL (Gerrit Change I216cdd68014173aa65cad42ddd3d870334be9ead)",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['Related URL: GERRIT_URL (Gerrit Change I216cdd68014173aa65cad42ddd3d870334be9ead)']",NA,1,"Related URL: GERRIT_URL (Gerrit Change I216cdd68014173aa65cad42ddd3d870334be9ead)" -5448,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","(In reply to comment #2) -> EditPage uses msg: editingold[1]. -> -> [1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en - -Ah, yes, whoops. Good catch.",1369256829,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","(In reply to comment #2) -> EditPage uses msg: editingold[1]. -> -> [1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en - -Ah, yes, whoops. Good catch.","(In reply to comment #2) -QUOTE -QUOTE -QUOTE - -Ah, yes, whoops. Good catch.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nAh, yes, whoops.', 'Good catch.']",NA,1,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nAh, yes, whoops." -5448,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","(In reply to comment #2) -> EditPage uses msg: editingold[1]. -> -> [1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en - -Ah, yes, whoops. Good catch.",1369256829,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","(In reply to comment #2) -> EditPage uses msg: editingold[1]. -> -> [1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en - -Ah, yes, whoops. Good catch.","(In reply to comment #2) -QUOTE -QUOTE -QUOTE - -Ah, yes, whoops. Good catch.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nAh, yes, whoops.', 'Good catch.']",NA,1,"Good catch." -5449,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","EditPage uses msg: editingold[1]. - -[1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en",1369244923,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","EditPage uses msg: editingold[1]. - -[1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en","EditPage uses msg: editingold[1]. - -[1] URL",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['EditPage uses msg: editingold[1].', '[1] URL']",NA,1,"EditPage uses msg: editingold[1]." -5449,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","EditPage uses msg: editingold[1]. - -[1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en",1369244923,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","EditPage uses msg: editingold[1]. - -[1] https://www.mediawiki.org/wiki/MediaWiki:Editingold/en","EditPage uses msg: editingold[1]. - -[1] URL",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['EditPage uses msg: editingold[1].', '[1] URL']",NA,1,"[1] URL" -5450,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","This looks to be . :-)",1367275878,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","This looks to be . :-)","This looks to be . :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['This looks to be .', ':-)']",NA,1,"This looks to be ." -5450,"VisualEditor: Warn the user more prominently that they are editing an out-dated version of the page","This looks to be . :-)",1367275878,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-hmeryxjc5h5ucj6zkjj7","task_subcomment","This looks to be . :-)","This looks to be . :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-9,NA,"['This looks to be .', ':-)']",NA,1,":-)" -5505,"VisualEditor: Round-tripping failure - Extra newline added at end of body","When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal",1366312920,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-akpipntp36njlfgkew56","task_description","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1368557767,NA,"resolved","True","c1",1,"True","False",-11,NA,"['VisualEditor: Round-tripping failure - Extra newline added at end of body.', 'When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end.', 'This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Round-tripping failure - Extra newline added at end of body." -5505,"VisualEditor: Round-tripping failure - Extra newline added at end of body","When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal",1366312920,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-akpipntp36njlfgkew56","task_description","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1368557767,NA,"resolved","True","c1",1,"True","False",-11,NA,"['VisualEditor: Round-tripping failure - Extra newline added at end of body.', 'When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end.', 'This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end." -5505,"VisualEditor: Round-tripping failure - Extra newline added at end of body","When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal",1366312920,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-akpipntp36njlfgkew56","task_description","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1368557767,NA,"resolved","True","c1",1,"True","False",-11,NA,"['VisualEditor: Round-tripping failure - Extra newline added at end of body.', 'When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end.', 'This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext." -5505,"VisualEditor: Round-tripping failure - Extra newline added at end of body","When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal",1366312920,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-akpipntp36njlfgkew56","task_description","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","VisualEditor: Round-tripping failure - Extra newline added at end of body./n/nWhen loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end. This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext. - --------------------------- -**Version**: unspecified -**Severity**: normal","High",80,1368557767,NA,"resolved","True","c1",1,"True","False",-11,NA,"['VisualEditor: Round-tripping failure - Extra newline added at end of body.', 'When loading a page into VE and exporting it again with a minor edit, an extra newline is added at the end.', 'This shows up as a diff in the DOM, and will result in an extra newline in the serialized wikitext.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal" -5506,"VisualEditor: Round-tripping failure - Extra newline added at end of body","(In reply to comment #3) -> This might be fixed by bug 48344. -It most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine). Closing this bug unless and until someone can get a newline to show up again.",1368557767,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-akpipntp36njlfgkew56","task_subcomment","(In reply to comment #3) -> This might be fixed by bug 48344. -It most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine). Closing this bug unless and until someone can get a newline to show up again.","(In reply to comment #3) -QUOTE -It most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine). Closing this bug unless and until someone can get a newline to show up again.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-7,NA,"[""(In reply to comment #3)\nQUOTE\nIt most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine)."", 'Closing this bug unless and until someone can get a newline to show up again.']",NA,0,"Closing this bug unless and until someone can get a newline to show up again." -5506,"VisualEditor: Round-tripping failure - Extra newline added at end of body","(In reply to comment #3) -> This might be fixed by bug 48344. -It most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine). Closing this bug unless and until someone can get a newline to show up again.",1368557767,"PHID-USER-fovtl67ew4l4cc3oeypc","PHID-TASK-akpipntp36njlfgkew56","task_subcomment","(In reply to comment #3) -> This might be fixed by bug 48344. -It most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine). Closing this bug unless and until someone can get a newline to show up again.","(In reply to comment #3) -QUOTE -It most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine). Closing this bug unless and until someone can get a newline to show up again.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-7,NA,"[""(In reply to comment #3)\nQUOTE\nIt most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine)."", 'Closing this bug unless and until someone can get a newline to show up again.']",NA,0,"(In reply to comment #3)\nQUOTE\nIt most probably is, yes (bug 48344 is only fixed when selser is on, but it's on in production so that's fine)." -5507,"VisualEditor: Round-tripping failure - Extra newline added at end of body","This might be fixed by bug 48344.",1368552325,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-akpipntp36njlfgkew56","task_subcomment","This might be fixed by bug 48344.","This might be fixed by bug 48344.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-7,NA,"['This might be fixed by bug 48344.']",NA,0,"This might be fixed by bug 48344." -5508,"VisualEditor: Round-tripping failure - Extra newline added at end of body","Eh, disregard that link- belongs to bug 47419.",1366388820,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-akpipntp36njlfgkew56","task_subcomment","Eh, disregard that link- belongs to bug 47419.","Eh, disregard that link- belongs to bug 47419.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-11,NA,"['Eh, disregard that link- belongs to bug 47419.']",NA,0,"Eh, disregard that link- belongs to bug 47419." -5509,"VisualEditor: Round-tripping failure - Extra newline added at end of body","Example edit: https://en.wikipedia.org/w/index.php?title=User:Fluffernutter/Kinne&curid=37842561&diff=551148728&oldid=551148307",1366388778,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-akpipntp36njlfgkew56","task_subcomment","Example edit: https://en.wikipedia.org/w/index.php?title=User:Fluffernutter/Kinne&curid=37842561&diff=551148728&oldid=551148307","Example edit: URL",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-11,NA,"['Example edit: URL']",NA,0,"Example edit: URL" -6148,"VisualEditor: Text duplication when using jquery.IME on existing pages","Screenshot showing text duplication - -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 - -The entire test procedure is as follows: - -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit - -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. - -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. - -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 - --------------------------- -**Version**: unspecified -**Severity**: normal - -**Attached**: {F11824}",1379764980,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_description","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication - -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 - -The entire test procedure is as follows: - -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit - -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. - -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. - -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 - --------------------------- -**Version**: unspecified -**Severity**: normal - -**Attached**: {F11824}","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication - -This bug was observed when continuing testing from URL - -The entire test procedure is as follows: - -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: URL -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. +I only wanted to change one section, but after pressing a link everything was opened in VE. Well, I added text to different sections. There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled. -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. +When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page. I've just read the digest of how good is the VE now and pushed ""Save page"", but after a time I've seen.........",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['**ignatus31oct** wrote:\n\n(One more example from En-wiki) See this edit (if your traffic is easy, the diff is half-Mb):\n\nURL\n\nI only wanted to change one section, but after pressing a link everything was opened in VE.', 'Well, I added text to different sections.', ""There were no trouble with it, except that when I tried to type text into ''()'' italicised parentheses leaved by previous editor, when I pushed [BackSpace] at end (wrongly started to type in Cyrillic rather than Latin), first ( was doubled."", 'When I entered enough and pushed ""Save"", I was introduced to type in the desc, and to view changes or to save page.', 'I\'ve just read the digest of how good is the VE now and pushed ""Save page"", but after a time I\'ve seen.........']",NA,0,"Save page" +535,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",1371221206,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for.', ""I'm going to go round and notify people now :)""]",NA,0,"Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for." +535,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",1371221206,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)","Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for. I'm going to go round and notify people now :)",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Also note; as you can see from the gerrit change above, it looks like Ariel and James will be temporarily disabling the VE until this is solved for.', ""I'm going to go round and notify people now :)""]",NA,0,"I'm going to go round and notify people now :)" +536,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)",1371221157,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)","Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)']",NA,0,"Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)" +537,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)",1371221153,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/68667 (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)","Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"['Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)']",NA,0,"Related URL: GERRIT_URL (Gerrit Change I267c8ba13a6ec1444010ce996fba05dfcba460fa)" +538,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",1371220263,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"[""A note; I've just spoken to James F; a fix to this is highest-priority."", ""I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).""]",NA,0,"A note; I've just spoken to James F; a fix to this is highest-priority." +538,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",1371220263,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-m3novk5xasw5lqvg62ye","task_subcomment","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).","A note; I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-3,NA,"[""A note; I've just spoken to James F; a fix to this is highest-priority."", ""I'm deeply sorry about this (and think I speak for James and the VE team on that front, too).""]",NA,0,"I'm deeply sorry about this (and think I speak for James and the VE team on that front, too)." +539,"New deployment of Parsoid leads to HTML insertion - needs deployed code reversion","(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 -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. +If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 +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 --------------------------- -**Version**: unspecified -**Severity**: normal +If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): -**Attached**: {F11824}","Medium",50,1453749177,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Text duplication when using jquery.IME on existing pages.', 'Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)', 'Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.', 'What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph.', 'So effectively the text is duplicated at the beginning of the page.', 'This means that first the caret moves to the beginning of the page, then the text is duplicated.', 'Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}']",FALSE,1,"VisualEditor: Text duplication when using jquery.IME on existing pages." -6148,"VisualEditor: Text duplication when using jquery.IME on existing pages","Screenshot showing text duplication +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 -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 +If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): -The entire test procedure is as follows: +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: -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m +https://de.wikipedia.org/w/index.php?title=Oper_K%C3%B6ln&curid=2386780&diff=119548868&oldid=118354900 -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit +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: -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. +https://de.wikipedia.org/w/index.php?title=Oper_K%C3%B6ln&curid=2386780&diff=119548868&oldid=118354900 -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. +https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174443&oldid=174442","More of this: -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 - --------------------------- -**Version**: unspecified -**Severity**: normal - -**Attached**: {F11824}",1379764980,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_description","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication - -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 - -The entire test procedure is as follows: - -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit - -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. - -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. - -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 - --------------------------- -**Version**: unspecified -**Severity**: normal - -**Attached**: {F11824}","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication - -This bug was observed when continuing testing from URL - -The entire test procedure is as follows: - -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: URL -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. +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). -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. +-------------------------- +**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). -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. +-------------------------- +**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). -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 +-------------------------- +**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**: {F11824}","Medium",50,1453749177,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Text duplication when using jquery.IME on existing pages.', 'Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)', 'Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.', 'What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph.', 'So effectively the text is duplicated at the beginning of the page.', 'This means that first the caret moves to the beginning of the page, then the text is duplicated.', 'Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}']",FALSE,1,"Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)" -6148,"VisualEditor: Text duplication when using jquery.IME on existing pages","Screenshot showing text duplication +**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 -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 +Original Bug title: VE: Page settings: Languages list cut off -The entire test procedure is as follows: - -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit - -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. - -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. - -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 +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**: {F11824}",1379764980,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_description","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication +**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 -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 +Original Bug title: VE: Page settings: Languages list cut off -The entire test procedure is as follows: - -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit - -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. - -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. - -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 +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**: {F11824}","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication +**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 -This bug was observed when continuing testing from URL +Original Bug title: VE: Page settings: Languages list cut off -The entire test procedure is as follows: +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) -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m +-------------------------- +**Version**: unspecified +**Severity**: normal -Test Url: +**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 -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. +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 -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. +By a template, you mean a template transclusion or the template itself? -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 +> 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**: {F11824}","Medium",50,1453749177,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Text duplication when using jquery.IME on existing pages.', 'Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)', 'Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.', 'What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph.', 'So effectively the text is duplicated at the beginning of the page.', 'This means that first the caret moves to the beginning of the page, then the text is duplicated.', 'Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}']",FALSE,1,"Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is." -6148,"VisualEditor: Text duplication when using jquery.IME on existing pages","Screenshot showing text duplication +**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 -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 +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"" -The entire test procedure is as follows: +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. -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit - -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. - -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. - -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 +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**: {F11824}",1379764980,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_description","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication +**Attached**: {F9591}","VisualEditor: Slug oddness - Prepending text to article starting with {{Infobox ..}} removes the entire article./n/nScreenshot showing the diff and the editor -This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3 +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"" -The entire test procedure is as follows: +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. -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m - -Test Url: -https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit - -Steps: -Enable ULS IME hindi transliteration -Take a caret to the end of the first paragraph using the mouse (i.e click at -the end of the first paragraph to take the caret there.) -Input ag -Output will be अग् as expected but with incorrect selection as reported in the comment linked above -Further input a -This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is. - -What should have happened: -The original output अग् should have been changed to अग at the end of the first paragraph. - -So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated. - -Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711 +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**: {F11824}","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication +**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 -This bug was observed when continuing testing from URL +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"" -The entire test procedure is as follows: +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. -System Environment: -Windows7 X64 SP1 -Google Chrome 29.0.1547.66 m +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:
 
-Test Url:
 URL
 
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+This might either be a selser issue, or VE dirtying the DOM.
 
 --------------------------
 **Version**: unspecified
-**Severity**: normal
+**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:
 
-**Attached**: {F11824}","Medium",50,1453749177,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Text duplication when using jquery.IME on existing pages.', 'Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)', 'Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.', 'What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph.', 'So effectively the text is duplicated at the beginning of the page.', 'This means that first the caret moves to the beginning of the page, then the text is duplicated.', 'Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}']",FALSE,1,"What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph."
-6148,"VisualEditor: Text duplication when using jquery.IME on existing pages","Screenshot showing text duplication
+http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387
 
-This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3
-
-The entire test procedure is as follows:
-
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
-
-Test Url:
-https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
-
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+This might either be a selser issue, or VE dirtying the DOM.
 
 --------------------------
 **Version**: unspecified
-**Severity**: normal
+**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:
 
-**Attached**: {F11824}",1379764980,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_description","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication
+http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387
 
-This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3
-
-The entire test procedure is as follows:
-
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
-
-Test Url:
-https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
-
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+This might either be a selser issue, or VE dirtying the DOM.
 
 --------------------------
 **Version**: unspecified
-**Severity**: normal
+**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:
 
-**Attached**: {F11824}","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication
-
-This bug was observed when continuing testing from URL
-
-The entire test procedure is as follows:
-
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
-
-Test Url:
 URL
 
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+This might either be a selser issue, or VE dirtying the DOM.
 
 --------------------------
 **Version**: unspecified
-**Severity**: normal
+**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:
 
-**Attached**: {F11824}","Medium",50,1453749177,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Text duplication when using jquery.IME on existing pages.', 'Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)', 'Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.', 'What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph.', 'So effectively the text is duplicated at the beginning of the page.', 'This means that first the caret moves to the beginning of the page, then the text is duplicated.', 'Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}']",FALSE,1,"So effectively the text is duplicated at the beginning of the page."
-6148,"VisualEditor: Text duplication when using jquery.IME on existing pages","Screenshot showing text duplication
+http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387
 
-This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3
-
-The entire test procedure is as follows:
-
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
-
-Test Url:
-https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
-
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+This might either be a selser issue, or VE dirtying the DOM.
 
 --------------------------
 **Version**: unspecified
-**Severity**: normal
+**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:
 
-**Attached**: {F11824}",1379764980,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_description","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication
+http://www.mediawiki.org/w/index.php?title=Parsoid&diff=779292&oldid=777387
 
-This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3
-
-The entire test procedure is as follows:
-
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
-
-Test Url:
-https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
-
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+This might either be a selser issue, or VE dirtying the DOM.
 
 --------------------------
 **Version**: unspecified
-**Severity**: normal
+**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:
 
-**Attached**: {F11824}","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication
-
-This bug was observed when continuing testing from URL
-
-The entire test procedure is as follows:
-
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
-
-Test Url:
 URL
 
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
+This might either be a selser issue, or VE dirtying the DOM.
 
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
+--------------------------
+**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
 
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
+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
 
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+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
 
-**Attached**: {F11824}","Medium",50,1453749177,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Text duplication when using jquery.IME on existing pages.', 'Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)', 'Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.', 'What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph.', 'So effectively the text is duplicated at the beginning of the page.', 'This means that first the caret moves to the beginning of the page, then the text is duplicated.', 'Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}']",FALSE,1,"This means that first the caret moves to the beginning of the page, then the text is duplicated."
-6148,"VisualEditor: Text duplication when using jquery.IME on existing pages","Screenshot showing text duplication
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3
+Expected output:
+a
+b
+c
+d
+e
 
-The entire test procedure is as follows:
+Actual output:
+abcde
 
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
+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.
 
-Test Url:
-https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
-
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+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
 
-**Attached**: {F11824}",1379764980,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_description","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-This bug was observed when continuing testing from https://bugzilla.wikimedia.org/show_bug.cgi?id=53706#c3
+Expected output:
+a
+b
+c
+d
+e
 
-The entire test procedure is as follows:
+Actual output:
+abcde
 
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
+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.
 
-Test Url:
-https://www.mediawiki.org/wiki/User:Siddhartha_Ghai/sandbox?veaction=edit
-
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+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
 
-**Attached**: {F11824}","VisualEditor: Text duplication when using jquery.IME on existing pages./n/nScreenshot showing text duplication
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-This bug was observed when continuing testing from URL
+Expected output:
+a
+b
+c
+d
+e
 
-The entire test procedure is as follows:
+Actual output:
+abcde
 
-System Environment:
-Windows7 X64 SP1
-Google Chrome 29.0.1547.66 m
+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.
 
-Test Url:
-URL
-
-Steps:
-Enable ULS IME hindi transliteration
-Take a caret to the end of the first paragraph using the mouse (i.e click at
-the end of the first paragraph to take the caret there.)
-Input ag
-Output will be अग् as expected but with incorrect selection as reported in the comment linked above
-Further input a
-This causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.
-
-What should have happened:
-The original output अग् should have been changed to अग at the end of the first paragraph.
-
-So effectively the text is duplicated at the beginning of the page. This means that first the caret moves to the beginning of the page, then the text is duplicated.
-
-Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711
+The problem has also been tested by trying to copy-paste html text from chrome itself. Newline is not copied.
 
 --------------------------
 **Version**: unspecified
 **Severity**: normal
-
-**Attached**: {F11824}","Medium",50,1453749177,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",11,NA,"['VisualEditor: Text duplication when using jquery.IME on existing pages.', 'Screenshot showing text duplication\n\nThis bug was observed when continuing testing from URL\n\nThe entire test procedure is as follows:\n\nSystem Environment:\nWindows7 X64 SP1\nGoogle Chrome 29.0.1547.66 m\n\nTest Url:\nURL\n\nSteps:\nEnable ULS IME hindi transliteration\nTake a caret to the end of the first paragraph using the mouse (i.e click at\nthe end of the first paragraph to take the caret there.)', 'Input ag\nOutput will be अग् as expected but with incorrect selection as reported in the comment linked above\nFurther input a\nThis causes the text अग to show up at the beginning of the page with the text अग् at the end of the first paragraph remaining as it is.', 'What should have happened:\nThe original output अग् should have been changed to अग at the end of the first paragraph.', 'So effectively the text is duplicated at the beginning of the page.', 'This means that first the caret moves to the beginning of the page, then the text is duplicated.', 'Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}']",FALSE,1,"Note: The text is navigable and removable, so this is different from Bug 53708 and Bug 53711\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n\n**Attached**: {F11824}"
-6149,"VisualEditor: Text duplication when using jquery.IME on existing pages","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.",1453749108,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-qb2engnawhn3el2wqyzm","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,1,"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."
-6150,"VisualEditor: Text duplication when using jquery.IME on existing pages","Automatic Incorrect caret movement has been reported separately as Bug 54424",1379768763,"PHID-USER-4bjsher5mqcoikeqnnec","PHID-TASK-qb2engnawhn3el2wqyzm","task_subcomment","Automatic Incorrect caret movement has been reported separately as Bug 54424","Automatic Incorrect caret movement has been reported separately as Bug 54424",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,11,NA,"['Automatic Incorrect caret movement has been reported separately as Bug 54424']",NA,1,"Automatic Incorrect caret movement has been reported separately as Bug 54424"
-6308,"VisualEditor: Investigate where we can replace setTimeouts with EventSequencer","For example, onBeforePaste/onAfterPaste in ve.ce.Surface
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1378834020,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-wh766os42bllzvmszxya","task_description","VisualEditor: Investigate where we can replace setTimeouts with EventSequencer./n/nFor example, onBeforePaste/onAfterPaste in ve.ce.Surface
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Investigate where we can replace setTimeouts with EventSequencer./n/nFor example, onBeforePaste/onAfterPaste in ve.ce.Surface
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"True","False",10,NA,"['VisualEditor: Investigate where we can replace setTimeouts with EventSequencer.', 'For example, onBeforePaste/onAfterPaste in ve.ce.Surface\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"VisualEditor: Investigate where we can replace setTimeouts with EventSequencer."
-6308,"VisualEditor: Investigate where we can replace setTimeouts with EventSequencer","For example, onBeforePaste/onAfterPaste in ve.ce.Surface
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1378834020,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-wh766os42bllzvmszxya","task_description","VisualEditor: Investigate where we can replace setTimeouts with EventSequencer./n/nFor example, onBeforePaste/onAfterPaste in ve.ce.Surface
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Investigate where we can replace setTimeouts with EventSequencer./n/nFor example, onBeforePaste/onAfterPaste in ve.ce.Surface
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"True","False",10,NA,"['VisualEditor: Investigate where we can replace setTimeouts with EventSequencer.', 'For example, onBeforePaste/onAfterPaste in ve.ce.Surface\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"For example, onBeforePaste/onAfterPaste in ve.ce.Surface\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement"
-6309,"VisualEditor: Investigate where we can replace setTimeouts with EventSequencer","Thanks, looks like I hadn't properly updated my copy of VE to master. :P",1378839634,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wh766os42bllzvmszxya","task_subcomment","Thanks, looks like I hadn't properly updated my copy of VE to master. :P","Thanks, looks like I hadn't properly updated my copy of VE to master. :P",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"[""Thanks, looks like I hadn't properly updated my copy of VE to master."", ':P']",NA,1,":P"
-6309,"VisualEditor: Investigate where we can replace setTimeouts with EventSequencer","Thanks, looks like I hadn't properly updated my copy of VE to master. :P",1378839634,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wh766os42bllzvmszxya","task_subcomment","Thanks, looks like I hadn't properly updated my copy of VE to master. :P","Thanks, looks like I hadn't properly updated my copy of VE to master. :P",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"[""Thanks, looks like I hadn't properly updated my copy of VE to master."", ':P']",NA,1,"Thanks, looks like I hadn't properly updated my copy of VE to master."
-6310,"VisualEditor: Investigate where we can replace setTimeouts with EventSequencer","(In reply to comment #1)
-> Got a reference doc for EventSequencer?
-
-https://doc.wikimedia.org/VisualEditor/master/#!/api/ve.EventSequencer",1378839518,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-wh766os42bllzvmszxya","task_subcomment","(In reply to comment #1)
-> Got a reference doc for EventSequencer?
-
-https://doc.wikimedia.org/VisualEditor/master/#!/api/ve.EventSequencer","(In reply to comment #1)
-QUOTE
-
-URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['(In reply to comment #1)\nQUOTE\n\nURL']",NA,1,"(In reply to comment #1)\nQUOTE\n\nURL"
-6311,"VisualEditor: Investigate where we can replace setTimeouts with EventSequencer","Got a reference doc for EventSequencer?",1378839441,"PHID-USER-yek7ymogrv4qc67oilhf","PHID-TASK-wh766os42bllzvmszxya","task_subcomment","Got a reference doc for EventSequencer?","Got a reference doc for EventSequencer?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"['Got a reference doc for EventSequencer?']",NA,1,"Got a reference doc for EventSequencer?"
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
---------------------------
 **See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-``CODE``
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"User preferences are inconsistently stored (bool/int as default, string for overrides)."
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-``CODE``
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"Just look at my mw.user.options table added below."
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-``CODE``
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"1 vs true vs ""1""."
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-``CODE``
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"Worse yet, check the inconsistency in Gadgets."
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
+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
 
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
+Steps to reproduce:
+Open a page
+Edit it in VE
+Copy-paste the following text:
+a
+b
+c
+d
+e
 
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
+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.
 
-``CODE``
 --------------------------
+**Version**: unspecified
+**Severity**: normal
 **See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"Gadgets enabled by default return 1 and gadgets enabled by the user return ""1""."
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
---------------------------
-**See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
---------------------------
-**See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-``CODE``
---------------------------
-**See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed."
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
---------------------------
-**See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
---------------------------
-**See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-``CODE``
---------------------------
-**See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"``CODE``\n--------------------------\n**See Also**:\n{T29471}"
-7068,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Just look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
---------------------------
-**See Also**:
-{T29471}",1375702860,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-yfjwr3je2btidmhmuccx","task_description","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-```
-aftv5-last-filter: null
-ccmeonemails: 0
-cols: ""120""
-date: ""mdy""
-diffonly: ""1""
-disablemail: 0
-disablesuggest: 0
-echo-email-format: ""html""
-echo-email-frequency: 0
-echo-notify-show-link: true
-echo-show-alert: true
-echo-subscriptions-email-article-linked: false
-echo-subscriptions-email-edit-thank: false
-echo-subscriptions-email-edit-user-talk: 1
-echo-subscriptions-email-mention: false
-echo-subscriptions-email-other: false
-echo-subscriptions-email-page-review: false
-echo-subscriptions-email-reverted: false
-echo-subscriptions-email-system: true
-echo-subscriptions-web-article-linked: ""1""
-echo-subscriptions-web-edit-thank: true
-echo-subscriptions-web-edit-user-talk: true
-echo-subscriptions-web-mention: true
-echo-subscriptions-web-other: true
-echo-subscriptions-web-page-review: true
-echo-subscriptions-web-reverted: true
-echo-subscriptions-web-system: true
-editfont: ""default""
-editondblclick: 0
-editsection: 1
-editsectiononrightclick: 0
-enotifminoredits: 0
-enotifrevealaddr: 0
-enotifusertalkpages: 1
-enotifwatchlistpages: 0
-ep_bulkdelcourses: true
-ep_bulkdelorgs: false
-ep_showdyk: true
-ep_showtoplink: false
-extendwatchlist: 0
-fancysig: ""1""
-flaggedrevseditdiffs: true
-flaggedrevssimpleui: 1
-flaggedrevsstable: 0
-flaggedrevsviewdiffs: false
-forceeditsummary: ""1""
-gadget-BugStatusUpdate: ""1""
-gadget-DRN-wizard: 1
-gadget-HotCat: ""1""
-gadget-Navigation_popups: ""1""
-gadget-NoAnimations: ""1""
-gadget-PrintOptions: ""1""
-gadget-ReferenceTooltips: 1
-gadget-UTCLiveClock: ""1""
-gadget-addsection-plus: ""1""
-gadget-charinsert: 1
-gadget-contribsrange: ""1""
-gadget-edittop: ""1""
-gadget-exlinks: ""1""
-gadget-metadata: ""1""
-gadget-mySandbox: 1
-gadget-purgetab: ""1""
-gadget-teahouse: 1
-gadget-widensearch: ""1""
-gadget-wikEd: ""1""
-gadget-wikEdDiff: ""1""
-gender: ""male""
-gettingstarted-task-toolbar-show-intro: """"
-hideminor: 0
-hidepatrolled: 0
-imagesize: 2
-justify: 0
-language: ""en""
-math: ""6""
-mfWatchlistFilter: ""all""
-mfWatchlistView: ""feed""
-minordefault: 0
-newpageshidepatrolled: 0
-nocache: 0
-noconvertlink: 0
-norollbackdiff: 0
-numberheadings: 0
-previewonfirst: 0
-previewontop: 1
-rcdays: 7
-rclimit: 50
-rcshowwikidata: ""1""
-rememberpassword: 0
-rows: ""30""
-searchNs0: true
-searchNs1: false
-searchNs2: false
-searchNs3: false
-searchNs4: false
-searchNs5: false
-searchNs6: false
-searchNs7: false
-searchNs8: false
-searchNs9: false
-searchNs10: false
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-searchNs15: false
-searchNs100: false
-searchNs101: false
-searchNs108: false
-searchNs109: false
-searchNs446: false
-searchNs447: false
-searchNs710: false
-searchNs711: false
-searchNs828: false
-searchNs829: false
-searchlimit: 20
-showhiddencats: ""1""
-showjumplinks: 1
-shownumberswatching: 1
-showtoc: 1
-showtoolbar: 1
-skin: ""vector""
-stubthreshold: ""2000""
-thumbsize: 4
-timecorrection: ""ZoneInfo|120|Europe/Amsterdam""
-uls-preferences: """"
-underline: 2
-usebetatoolbar: 1
-usebetatoolbar-cgd: 1
-useeditwarning: 1
-uselivepreview: 0
-usenewrc: ""1""
-userjs-curationtoolbar: ""hidden""
-variant: ""en""
-vector-collapsiblenav: 1
-vector-simplesearch: 1
-visualeditor-betatempdisable: 0
-visualeditor-enable: 1
-watchcreations: 1
-watchdefault: 0
-watchdeletion: 0
-watchlistdays: 3
-watchlisthideanons: 0
-watchlisthidebots: 0
-watchlisthideliu: 0
-watchlisthideminor: 0
-watchlisthideown: 0
-watchlisthidepatrolled: 0
-watchmoves: 0
-wikilove-enabled: 1
-wllimit: 250
-wlshowwikibase: ""1""
-```
---------------------------
-**See Also**:
-{T29471}","User preferences are inconsistently stored (bool/int as default, string for overrides)./n/nJust look at my mw.user.options table added below. 1 vs true vs ""1"". I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?
-
-Worse yet, check the inconsistency in Gadgets. Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".
-
-We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.
-
-``CODE``
---------------------------
-**See Also**:
-{T29471}","Medium",50,NA,NA,"open","True","c1",3,"True","False",5,NA,"['User preferences are inconsistently stored (bool/int as default, string for overrides).', 'Just look at my mw.user.options table added below.', '1 vs true vs ""1"".', ""I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"", 'Worse yet, check the inconsistency in Gadgets.', 'Gadgets enabled by default return 1 and gadgets enabled by the user return ""1"".', 'We should really do a bit of clean up here, and possibly even cleanup the existing values in tables, this makes coding JS against these pages more fragile than needed.', '``CODE``\n--------------------------\n**See Also**:\n{T29471}']",FALSE,0,"I'm in favor of using numbers over booleans here, but why do we have string values for numbers ?"
-7069,"User preferences are inconsistently stored (bool/int as default, string for overrides)","@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
-
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).",1519100508,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
-
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).","SCREEN_NAME I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
-
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"[""SCREEN_NAME I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies."", 'This task is about inconsistencies within a single key.', 'Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).']",NA,0,"This task is about inconsistencies within a single key."
-7069,"User preferences are inconsistently stored (bool/int as default, string for overrides)","@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
-
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).",1519100508,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
-
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).","SCREEN_NAME I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
+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
 
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"[""SCREEN_NAME I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies."", 'This task is about inconsistencies within a single key.', 'Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).']",NA,0,"Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row)."
-7069,"User preferences are inconsistently stored (bool/int as default, string for overrides)","@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
+https://gerrit.wikimedia.org/r/86664",1385500082,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-3yhieue5lg5ipuzhildn","task_subcomment","Change 86664 merged by jenkins-bot:
+Rich paste
 
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).",1519100508,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
+https://gerrit.wikimedia.org/r/86664","Change 86664 merged by jenkins-bot:
+Rich paste
 
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).","SCREEN_NAME I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
+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
 
-This task is about inconsistencies within a single key. Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"[""SCREEN_NAME I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies."", 'This task is about inconsistencies within a single key.', 'Where the same logical value of the same preference key can be int, int-ish string, or boolean, depending on how/if it got normalised, and where it came from (PHP default or MySQL row).']",NA,0,"SCREEN_NAME I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies."
-7070,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Also, just to note that `email-blacklist` is another outlier and is actually an array.",1519099509,"PHID-USER-hlhhe6qw6qfkl7wyfhxk","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Also, just to note that `email-blacklist` is another outlier and is actually an array.","Also, just to note that CODE is another outlier and is actually an array.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,242,NA,"['Also, just to note that CODE is another outlier and is actually an array.']",NA,0,"Also, just to note that CODE is another outlier and is actually an array."
-7071,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?",1519098837,"PHID-USER-hlhhe6qw6qfkl7wyfhxk","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,242,NA,"['Is it in scope for this task to tackle the storing of arrays in options?', 'e.g.', 'the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?']",NA,0,"Is it in scope for this task to tackle the storing of arrays in options?"
-7071,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?",1519098837,"PHID-USER-hlhhe6qw6qfkl7wyfhxk","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,242,NA,"['Is it in scope for this task to tackle the storing of arrays in options?', 'e.g.', 'the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?']",NA,0,"e.g."
-7071,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?",1519098837,"PHID-USER-hlhhe6qw6qfkl7wyfhxk","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?","Is it in scope for this task to tackle the storing of arrays in options? e.g. the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,242,NA,"['Is it in scope for this task to tackle the storing of arrays in options?', 'e.g.', 'the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?']",NA,0,"the differences between JSON strings (rcfilters-saved-queries), pipe-delimited (timecorrection), newline-delimited (email-blacklist), and what these should be exposed as?"
-7072,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+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
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479716929,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+https://gerrit.wikimedia.org/r/86664","Change 86664 had a related patch set uploaded by Esanders:
+Rich paste
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+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
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE."
-7072,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+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.
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479716929,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+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:
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+a
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"I have no idea why this task\"
-7072,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+b
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479716929,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+c
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+d
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High""."
-7072,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+e
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479716929,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+None of it makes the slightest bit of difference.
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+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
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."
-7072,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+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.
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479716929,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+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:
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+a
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code."
-7072,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+b
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479716929,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+c
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code.
+d
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which had borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"Low"
-7073,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+e
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479715550,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+None of it makes the slightest bit of difference.
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+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
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE."
-7073,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+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.
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479715550,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+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:
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+a
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"I have no idea why this task\"
-7073,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+b
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479715550,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+c
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+d
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High""."
-7073,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+e
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479715550,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+None of it makes the slightest bit of difference.
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+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
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."
-7073,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+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.
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479715550,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+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:
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+a
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"Other wikis which borrowed code from us had the issue too, and they most probably won't update the code."
-7073,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+b
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",1479715550,"PHID-USER-p6gpvwnc6ske65oxuoof","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first `compact-language-links` user option was set to `""""` when switched off, but after some change switching it on and off turns it to `""0""`. (Was finally fixed [[https://ru.wikipedia.org/w/index.php?title=MediaWiki:Interwiki-links.js&diff=81404746&oldid=79892976|here]].) Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+c
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".","Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE. (Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce. Other wikis which borrowed code from us had the issue too, and they most probably won't update the code.
+d
 
-I have no idea why this task's priority is set to ""Low"". I don't know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,177,NA,"['Hello, we at Russian Wikipedia had **months** of interwiki gadgets not working for some users, because at first CODE user option was set to CODE when switched off, but after some change switching it on and off turns it to CODE.', ""(Was finally fixed [[URL Those who switched the option off after that change had gadget not working, but the project engineers weren't able to reproduce."", ""Other wikis which borrowed code from us had the issue too, and they most probably won't update the code."", 'I have no idea why this task\'s priority is set to ""Low"".', 'I don\'t know the site policy regarding changing priorities, I will try change to ""Normal"" at least, maybe needs ""High"".']",NA,0,"Low"
-7074,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+e
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+None of it makes the slightest bit of difference.
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+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
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+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.
 
-Quite the mix up.
+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:
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1519100319,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+a
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+b
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+c
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+d
 
-Quite the mix up.
+e
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+None of it makes the slightest bit of difference.
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+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
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+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.
 
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the way into the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"Preferences has a filter for some values."
-7074,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+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:
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+a
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+b
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+c
 
-Quite the mix up.
+d
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1519100319,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+e
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+None of it makes the slightest bit of difference.
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+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
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+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.
 
-Quite the mix up.
+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:
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+a
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+b
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+c
 
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the way into the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"The search preferences, for example, are normalised to booleans."
-7074,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+d
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+e
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+None of it makes the slightest bit of difference.
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+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
 
-Quite the mix up.
+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.
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1519100319,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+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:
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+a
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+b
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+c
 
-Quite the mix up.
+d
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+e
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+None of it makes the slightest bit of difference.
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+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
 
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the way into the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"A few other are casted to integers."
-7074,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+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.
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+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:
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+a
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+b
 
-Quite the mix up.
+c
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1519100319,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+d
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+e
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+None of it makes the slightest bit of difference.
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+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
 
-Quite the mix up.
+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.
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+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:
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+a
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+b
 
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the way into the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"However the filters are only applied on the way into the database."
-7074,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+c
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+d
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+e
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+None of it makes the slightest bit of difference.
 
-Quite the mix up.
+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
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1519100319,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+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.
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+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:
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+a
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+b
 
-Quite the mix up.
+c
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+d
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+e
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+None of it makes the slightest bit of difference.
 
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the way into the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"On the way out they become strings regardless and nothing takes care of that."
-7074,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+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
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+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.
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+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:
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+a
 
-Quite the mix up.
+b
 
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1519100319,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
+c
 
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
+d
 
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
+e
 
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
+None of it makes the slightest bit of difference.
 
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the way into the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."
-7074,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1519100319,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the way into the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,242,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the way into the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types."
-7075,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1423877781,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,84,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the in to the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"Preferences has a filter for some values."
-7075,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1423877781,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,84,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the in to the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"The search preferences, for example, are normalised to booleans."
-7075,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1423877781,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,84,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the in to the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"A few other are casted to integers."
-7075,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1423877781,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,84,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the in to the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"However the filters are only applied on the in to the database."
-7075,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1423877781,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,84,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the in to the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"On the way out they become strings regardless and nothing takes care of that."
-7075,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1423877781,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,84,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the in to the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."
-7075,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",1423877781,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-```
-rclimit: 50
-rows: ""30""
-searchNs0: true
-searchNs1: false
-..
-searchNs10: ""1""
-searchNs11: false
-searchNs12: false
-searchNs13: false
-searchNs14: ""1""
-```
-
-Quite the mix up.
-
-Few thoughts: Applying it on the way out would be a good start. Though it's not a a great system to use for extensions. We could extend the preference descriptor array with a `kind` property (for int, bool or str). Or perhaps something we can derive from the `type` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ","Preferences has a filter for some values. The search preferences, for example, are normalised to booleans. A few other are casted to integers.
-
-However the filters are only applied on the in to the database. On the way out they become strings regardless and nothing takes care of that.
-
-So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:
-
-``CODE`CODEkindCODEtype` property (for HTMLForm field type). Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types. ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,84,NA,"['Preferences has a filter for some values.', 'The search preferences, for example, are normalised to booleans.', 'A few other are casted to integers.', 'However the filters are only applied on the in to the database.', 'On the way out they become strings regardless and nothing takes care of that.', ""So aside from the filters not being available to extension-provided preferences (it's a hardcoded privilege for core's own handling), even for the core ones, there's no normalisation on the way out:\n\n``CODE`CODEkindCODEtype` property (for HTMLForm field type)."", ""Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types.""]",NA,0,"Though the latter is extendable so we'd need to put it in the HTMLFormField class instead of simply having Preferences map the shortcuts to native types."
-7076,"User preferences are inconsistently stored (bool/int as default, string for overrides)","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.",1423875937,"PHID-USER-qgqq35kbi5wss2tlgmhg","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,84,NA,"['I have had similar difficulties and personally prefer booleans wherever possible.', ""They're more reliable and less likely to be unpredictable."", ""They are either true or false or they're invalid.""]",NA,0,"I have had similar difficulties and personally prefer booleans wherever possible."
-7076,"User preferences are inconsistently stored (bool/int as default, string for overrides)","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.",1423875937,"PHID-USER-qgqq35kbi5wss2tlgmhg","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,84,NA,"['I have had similar difficulties and personally prefer booleans wherever possible.', ""They're more reliable and less likely to be unpredictable."", ""They are either true or false or they're invalid.""]",NA,0,"They're more reliable and less likely to be unpredictable."
-7076,"User preferences are inconsistently stored (bool/int as default, string for overrides)","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.",1423875937,"PHID-USER-qgqq35kbi5wss2tlgmhg","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.","I have had similar difficulties and personally prefer booleans wherever possible.  They're more reliable and less likely to be unpredictable.  They are either true or false or they're invalid.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,84,NA,"['I have had similar difficulties and personally prefer booleans wherever possible.', ""They're more reliable and less likely to be unpredictable."", ""They are either true or false or they're invalid.""]",NA,0,"They are either true or false or they're invalid."
-7077,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1466864706,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set CODE
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    CODE
-  - If I enable the preference
-    CODE
-* If I set CODE (as in WMF cluster[1]):
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,155,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', ""The current behavior is ***very*** inconvenient:\n* If I do not set CODE\n(i.e., if I use WikiEditor's default):\n  - If I don't change the preference\n    CODE\n  - If I enable the preference\n    CODE\n* If I set CODE (as in WMF cluster[1]):\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (non-empty string == true!)"", ""* On English Wikipedia\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (empty string!)"", '[1] URL']",NA,0,"(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else."
-7077,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1466864706,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set CODE
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    CODE
-  - If I enable the preference
-    CODE
-* If I set CODE (as in WMF cluster[1]):
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,155,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', ""The current behavior is ***very*** inconvenient:\n* If I do not set CODE\n(i.e., if I use WikiEditor's default):\n  - If I don't change the preference\n    CODE\n  - If I enable the preference\n    CODE\n* If I set CODE (as in WMF cluster[1]):\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (non-empty string == true!)"", ""* On English Wikipedia\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (empty string!)"", '[1] URL']",NA,0,"[1] URL"
-7077,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1466864706,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set CODE
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    CODE
-  - If I enable the preference
-    CODE
-* If I set CODE (as in WMF cluster[1]):
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,155,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', ""The current behavior is ***very*** inconvenient:\n* If I do not set CODE\n(i.e., if I use WikiEditor's default):\n  - If I don't change the preference\n    CODE\n  - If I enable the preference\n    CODE\n* If I set CODE (as in WMF cluster[1]):\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (non-empty string == true!)"", ""* On English Wikipedia\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (empty string!)"", '[1] URL']",NA,0,"The current behavior is ***very*** inconvenient:\n* If I do not set CODE\n(i.e., if I use WikiEditor's default):\n  - If I don't change the preference\n    CODE\n  - If I enable the preference\n    CODE\n* If I set CODE (as in WMF cluster[1]):\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (non-empty string == true!)"
-7077,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1466864706,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> `mw.user.options.get( 'anyBooleanPreference' ) === true`
-> `mw.user.options.get( 'anyBooleanPreference' ) === false`
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set `$wgDefaultUserOptions['usebetatoolbar']`
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === null`
-  - If I enable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""1""`
-* If I set `$wgDefaultUserOptions['usebetatoolbar'] = 1` (as in WMF cluster[1]):
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === ""0""` (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === 1`
-  - If I disable the preference
-    `mw.user.options.get( 'usebetatoolbar' ) === """"` (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set CODE
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    CODE
-  - If I enable the preference
-    CODE
-* If I set CODE (as in WMF cluster[1]):
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    CODE
-  - If I disable the preference
-    CODE (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,155,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', ""The current behavior is ***very*** inconvenient:\n* If I do not set CODE\n(i.e., if I use WikiEditor's default):\n  - If I don't change the preference\n    CODE\n  - If I enable the preference\n    CODE\n* If I set CODE (as in WMF cluster[1]):\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (non-empty string == true!)"", ""* On English Wikipedia\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (empty string!)"", '[1] URL']",NA,0,"* On English Wikipedia\n  - If I don't change the preference\n    CODE\n  - If I disable the preference\n    CODE (empty string!)"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else."
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"]\n(i.e., if I use WikiEditor\"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"t change the preference\n    mw.user.options.get( \"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0," ) === null\n  - If I enable the preference\n    mw.user.options.get( \"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0," ) === ""1""\n* If I set $wgDefaultUserOptions[\"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"] = 1 (as in WMF cluster[1]):\n  - If I don\"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"usebetatoolbar\"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"usebetatoolbar\"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"t change the preference\n    mw.user.options.get( \"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0," ) === 1\n  - If I disable the preference\n    mw.user.options.get( \"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0," ) === """" (empty string!)"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"[1] URL"
-7078,"User preferences are inconsistently stored (bool/int as default, string for overrides)","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641",1408812707,"PHID-USER-sryrz6tgcfnnsiddx32p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","(In reply to Bartosz Dziewoński from comment #1)
-> ...
-> normalizing values of boolean prefs to true/false just before building this
-> list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.
-
-+1 for normalizing boolean preferences so that either
-> mw.user.options.get( 'anyBooleanPreference' ) === true
-> mw.user.options.get( 'anyBooleanPreference' ) === false
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] https://github.com/wikimedia/operations-mediawiki-config/blob/8178a4994c0137f5171798f3e831c0492c8cbc06/wmf-config/CommonSettings.php#L1641","(In reply to Bartosz Dziewoński from comment #1)
-QUOTE
-QUOTE
-QUOTE
-
-+1 for normalizing boolean preferences so that either
-QUOTE
-QUOTE
-and nothing else.
-
-The current behavior is ***very*** inconvenient:
-* If I do not set $wgDefaultUserOptions['usebetatoolbar']
-(i.e., if I use WikiEditor's default):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === null
-  - If I enable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""1""
-* If I set $wgDefaultUserOptions['usebetatoolbar'] = 1 (as in WMF cluster[1]):
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === ""0"" (non-empty string == true!)
-* On English Wikipedia
-  - If I don't change the preference
-    mw.user.options.get( 'usebetatoolbar' ) === 1
-  - If I disable the preference
-    mw.user.options.get( 'usebetatoolbar' ) === """" (empty string!)
-
-[1] URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,59,NA,"['(In reply to Bartosz Dziewoński from comment #1)\nQUOTE\nQUOTE\nQUOTE\n\n+1 for normalizing boolean preferences so that either\nQUOTE\nQUOTE\nand nothing else.', 'The current behavior is ***very*** inconvenient:\n* If I do not set $wgDefaultUserOptions[\'usebetatoolbar\']\n(i.e., if I use WikiEditor\'s default):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === null\n  - If I enable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""1""\n* If I set $wgDefaultUserOptions[\'usebetatoolbar\'] = 1 (as in WMF cluster[1]):\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === ""0"" (non-empty string == true!)', '* On English Wikipedia\n  - If I don\'t change the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === 1\n  - If I disable the preference\n    mw.user.options.get( \'usebetatoolbar\' ) === """" (empty string!)', '[1] URL']",NA,0,"0"
-7079,"User preferences are inconsistently stored (bool/int as default, string for overrides)","The integer came from $wgDefaultSettings. Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.",1375735877,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","The integer came from $wgDefaultSettings. Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.","The integer came from $wgDefaultSettings. Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['The integer came from $wgDefaultSettings.', 'Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.']",NA,0,"The integer came from $wgDefaultSettings."
-7079,"User preferences are inconsistently stored (bool/int as default, string for overrides)","The integer came from $wgDefaultSettings. Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.",1375735877,"PHID-USER-a6jwrurphpx6yl4coupk","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","The integer came from $wgDefaultSettings. Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.","The integer came from $wgDefaultSettings. Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,5,NA,"['The integer came from $wgDefaultSettings.', 'Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings.']",NA,0,"Set it to string there and it should work, except gadget and maybe the searchNs, because that are dynamically preferences, where the default is not stored in $wgDefaultSettings."
-7080,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",1375703425,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,5,NA,"['Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).', 'Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null.', 'You should just check for truthiness in this case.', ""I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.""]",NA,0,"Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them)."
-7080,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",1375703425,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,5,NA,"['Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).', 'Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null.', 'You should just check for truthiness in this case.', ""I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.""]",NA,0,"Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null."
-7080,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",1375703425,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,5,NA,"['Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).', 'Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null.', 'You should just check for truthiness in this case.', ""I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.""]",NA,0,"You should just check for truthiness in this case."
-7080,"User preferences are inconsistently stored (bool/int as default, string for overrides)","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",1375703425,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-yfjwr3je2btidmhmuccx","task_subcomment","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.","Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).
-
-Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null. You should just check for truthiness in this case.
-
-I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,5,NA,"['Values that are actually saved in the database (ie, non-default ones) are always strings, and apparently usually equal to ""1"" (but for boolean prefs any truthy value is technically possible, especially if one uses the API to set them).', 'Values that are default ones are equal to whatever the programmer decided, and as you can see they might be 1/0, true/false, ""1""/""0"" or null.', 'You should just check for truthiness in this case.', ""I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way.""]",NA,0,"I'm not sure how to solve this, or whether we actually want to solve this; normalizing values of boolean prefs to true/false just before building this list (in ResourceLoaderUserOptionsModule#getScript) seems like the best way."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"He asks whether this should be offered to VE users while it does not support redirects."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"In other cases the different display formats (e.g."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact."
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement"
-7092,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1375469280,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_description","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors./n/nen.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to. He asks whether this should be offered to VE users while it does not support redirects.
-
-However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors. There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.
-
-There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant. In other cases the different display formats (e.g. generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.
-
-As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response. Sort of a:
-IF editor=""VisualEditor"" THEN do X ELSE do Y
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Medium",50,NA,NA,"open","True","c1",3,"False","False",4,NA,"['VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors.', 'en.wp user Andrew Gray notes that on creating a page in VE he is given several alternatives to writing a new article, one of which is to search for an existing page to redirect the title to.', 'He asks whether this should be offered to VE users while it does not support redirects.', 'However, the message is provided by [[MediaWiki:Newarticletext]] and the text is served identically in the source and visual editors.', 'There is no current mechanism to detect in which editor it is being displayed so different content cannot be provided.', 'There will be occasions where such messages and also edit notices are only relevant to either source or visual editor users or are differently relevant.', 'In other cases the different display formats (e.g.', 'generally horizontal in source, generally vertical in visual) may lead to different presentation choices for optimum impact.', ""As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."", 'Sort of a:\nIF editor=""VisualEditor"" THEN do X ELSE do Y\n\n--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,0,"As it is not inconceivable that there will in future be other editors (developed by WMF or others) there should be some way for the editor to uniquely declare itself to such messages and for them to be able to determine what they do if they don't recognise the response."
-7093,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","I don't think there should be a control for separate interface messages.
-
-However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.",1378320091,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-lusyegvtclbce7nfsesb","task_subcomment","I don't think there should be a control for separate interface messages.
-
-However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.","I don't think there should be a control for separate interface messages.
-
-However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,9,NA,"[""I don't think there should be a control for separate interface messages."", 'However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.']",NA,0,"However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces."
-7093,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","I don't think there should be a control for separate interface messages.
-
-However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.",1378320091,"PHID-USER-sai77mtxmpqnm6pycyvz","PHID-TASK-lusyegvtclbce7nfsesb","task_subcomment","I don't think there should be a control for separate interface messages.
-
-However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.","I don't think there should be a control for separate interface messages.
-
-However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,9,NA,"[""I don't think there should be a control for separate interface messages."", 'However either way, meanwhile a workaround is to use a CSS selector (.ve-available or .ve-not-available) to hide or display certain pieces.']",NA,0,"I don't think there should be a control for separate interface messages."
-7094,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","Yes, that does sound far simpler to implement! More difficult to keep the two in synch, but I suppose you can't have everything.",1375472876,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_subcomment","Yes, that does sound far simpler to implement! More difficult to keep the two in synch, but I suppose you can't have everything.","Yes, that does sound far simpler to implement! More difficult to keep the two in synch, but I suppose you can't have everything.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,4,NA,"['Yes, that does sound far simpler to implement!', ""More difficult to keep the two in synch, but I suppose you can't have everything.""]",NA,0,"Yes, that does sound far simpler to implement!"
-7094,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","Yes, that does sound far simpler to implement! More difficult to keep the two in synch, but I suppose you can't have everything.",1375472876,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-lusyegvtclbce7nfsesb","task_subcomment","Yes, that does sound far simpler to implement! More difficult to keep the two in synch, but I suppose you can't have everything.","Yes, that does sound far simpler to implement! More difficult to keep the two in synch, but I suppose you can't have everything.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,4,NA,"['Yes, that does sound far simpler to implement!', ""More difficult to keep the two in synch, but I suppose you can't have everything.""]",NA,0,"More difficult to keep the two in synch, but I suppose you can't have everything."
-7095,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)",1375470158,"PHID-USER-jnta3z3spxto3vbxdngm","PHID-TASK-lusyegvtclbce7nfsesb","task_subcomment","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,4,NA,"['One possible way to do this is using a different interface message for VE in such cases.', 'MediaWiki:Newarticletext-VE for example.', 'This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)']",NA,0,"One possible way to do this is using a different interface message for VE in such cases."
-7095,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)",1375470158,"PHID-USER-jnta3z3spxto3vbxdngm","PHID-TASK-lusyegvtclbce7nfsesb","task_subcomment","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,4,NA,"['One possible way to do this is using a different interface message for VE in such cases.', 'MediaWiki:Newarticletext-VE for example.', 'This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)']",NA,0,"MediaWiki:Newarticletext-VE for example."
-7095,"VisualEditor: Provide a way for interface messages, edit notices, etc to display different content to Visual and Source editors","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)",1375470158,"PHID-USER-jnta3z3spxto3vbxdngm","PHID-TASK-lusyegvtclbce7nfsesb","task_subcomment","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)","One possible way to do this is using a different interface message for VE in such cases. MediaWiki:Newarticletext-VE for example.
-
-This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,4,NA,"['One possible way to do this is using a different interface message for VE in such cases.', 'MediaWiki:Newarticletext-VE for example.', 'This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)']",NA,0,"This looks apparently more simple to do than creating yet another programming language to control such logic on the message itself ;)"
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
+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:**
-Steps to reproduce:
+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.
 
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Goto URL\n2."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Position the cursor at the start of the page directly before the bold ""T""."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"3."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Hit Backspace (to delete infobox)\n4."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Hit Ctrl+Z (undo)\n5."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Hit Backspace again\n6."
-7247,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1375008900,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_description","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** `jonathan_haas`
-
-**Description:**
-Steps to reproduce:
-
-1. Goto http://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph./n/n**Author:** CODE
-
-**Description:**
-Steps to reproduce:
-
-1. Goto URL
-2. Position the cursor at the start of the page directly before the bold ""T"".
-3. Hit Backspace (to delete infobox)
-4. Hit Ctrl+Z (undo)
-5. Hit Backspace again
-6. Hit Ctrl+Z again
-Repeat as long as you want
-
-Actual result:
-
-On each Ctrl+Z a paragraph more is selected
-
-Expected result:
-
-Selection stays the same, undo should undo the action and not change the selection
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1394503778,NA,"resolved","True","c1",3,"False","False",3,NA,"['VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph.', '**Author:** CODE\n\n**Description:**\nSteps to reproduce:\n\n1.', 'Goto URL\n2.', 'Position the cursor at the start of the page directly before the bold ""T"".', '3.', 'Hit Backspace (to delete infobox)\n4.', 'Hit Ctrl+Z (undo)\n5.', 'Hit Backspace again\n6.', 'Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal']",FALSE,0,"Hit Ctrl+Z again\nRepeat as long as you want\n\nActual result:\n\nOn each Ctrl+Z a paragraph more is selected\n\nExpected result:\n\nSelection stays the same, undo should undo the action and not change the selection\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal"
-7248,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","This was fixed in gerrit 115759 as part of fixing bug 57552.",1394503778,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_subcomment","This was fixed in gerrit 115759 as part of fixing bug 57552.","This was fixed in gerrit 115759 as part of fixing bug 57552.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,36,NA,"['This was fixed in gerrit 115759 as part of fixing bug 57552.']",NA,0,"This was fixed in gerrit 115759 as part of fixing bug 57552."
-7249,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**jonathan_haas** wrote:
-
-Deleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.
-
-In short: The problem is more hidden, but the underlying issue has not been fixed.",1382445971,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_subcomment","**jonathan_haas** wrote:
-
-Deleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.
-
-In short: The problem is more hidden, but the underlying issue has not been fixed.","**jonathan_haas** wrote:
-
-Deleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.
-
-In short: The problem is more hidden, but the underlying issue has not been fixed.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['**jonathan_haas** wrote:\n\nDeleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.', 'In short: The problem is more hidden, but the underlying issue has not been fixed.']",NA,0,"**jonathan_haas** wrote:\n\nDeleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2."
-7249,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","**jonathan_haas** wrote:
-
-Deleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.
-
-In short: The problem is more hidden, but the underlying issue has not been fixed.",1382445971,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_subcomment","**jonathan_haas** wrote:
-
-Deleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.
-
-In short: The problem is more hidden, but the underlying issue has not been fixed.","**jonathan_haas** wrote:
-
-Deleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.
-
-In short: The problem is more hidden, but the underlying issue has not been fixed.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['**jonathan_haas** wrote:\n\nDeleting infoboxes with a simple backspace has been disabled, but this is still somewhat reproducible, if you select an area (for example the infobox _and_ the bold T) in step 2.', 'In short: The problem is more hidden, but the underlying issue has not been fixed.']",NA,0,"In short: The problem is more hidden, but the underlying issue has not been fixed."
-7250,"VisualEditor: Selection expanded on undoing a deletion to cover the whole paragraph","Reproduced.",1375050421,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-3wvoqjxuqinfi7bgkax4","task_subcomment","Reproduced.","Reproduced.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Reproduced.']",NA,0,"Reproduced."
-7678,"Template search results list should contain each template's descripton","**Author:** `turingt`
-
-**Description:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
-
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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=51774",1373980800,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_description","Template search results list should contain each template's descripton./n/n**Author:** `turingt`
+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:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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=51774","Template search results list should contain each template's descripton./n/n**Author:** CODE
+https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** CODE
 
 **Description:**
-See this feedback trhead: [ URL ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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,1429285347,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",2,NA,"[""Template search results list should contain each template's descripton."", ""**Author:** CODE\n\n**Description:**\nSee this feedback trhead: [ URL ]\n\nThe search results for parameters include each parameter's description, making it easy to select the right one."", ""But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template)."", 'So, add the template description to the search results list.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"So, add the template description to the search results list."
-7678,"Template search results list should contain each template's descripton","**Author:** `turingt`
+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:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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=51774",1373980800,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_description","Template search results list should contain each template's descripton./n/n**Author:** `turingt`
+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:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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=51774","Template search results list should contain each template's descripton./n/n**Author:** CODE
+https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** CODE
 
 **Description:**
-See this feedback trhead: [ URL ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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,1429285347,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",2,NA,"[""Template search results list should contain each template's descripton."", ""**Author:** CODE\n\n**Description:**\nSee this feedback trhead: [ URL ]\n\nThe search results for parameters include each parameter's description, making it easy to select the right one."", ""But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template)."", 'So, add the template description to the search results list.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL"
-7678,"Template search results list should contain each template's descripton","**Author:** `turingt`
+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:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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=51774",1373980800,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_description","Template search results list should contain each template's descripton./n/n**Author:** `turingt`
+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:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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=51774","Template search results list should contain each template's descripton./n/n**Author:** CODE
+https://bugzilla.wikimedia.org/show_bug.cgi?id=52141","VisualEditor: 
 not always preventing editing in VE./n/n**Author:** CODE
 
 **Description:**
-See this feedback trhead: [ URL ]
+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.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
-
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
-
-So, add the template description to the search results list.
+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,1429285347,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",2,NA,"[""Template search results list should contain each template's descripton."", ""**Author:** CODE\n\n**Description:**\nSee this feedback trhead: [ URL ]\n\nThe search results for parameters include each parameter's description, making it easy to select the right one."", ""But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template)."", 'So, add the template description to the search results list.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"Template search results list should contain each template's descripton."
-7678,"Template search results list should contain each template's descripton","**Author:** `turingt`
+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:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+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`
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
+**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
 
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
+**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`
 
-So, add the template description to the search results list.
+**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=51774",1373980800,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_description","Template search results list should contain each template's descripton./n/n**Author:** `turingt`
+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
 
-**Description:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+This will allow mere mortals to help identify bugs with unsupported browsers.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
+For option four, we can modify the blacklist, like so:
 
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
+JS> delete mw.libs.ve.blacklist.opera;
 
-So, add the template description to the search results list.
+But im not sure what to do after that.
 
 --------------------------
 **Version**: unspecified
 **Severity**: enhancement
 **See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=51774","Template search results list should contain each template's descripton./n/n**Author:** CODE
+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
 
-**Description:**
-See this feedback trhead: [ URL ]
+This will allow mere mortals to help identify bugs with unsupported browsers.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
+For option four, we can modify the blacklist, like so:
 
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
+JS> delete mw.libs.ve.blacklist.opera;
 
-So, add the template description to the search results list.
+But im not sure what to do after that.
 
 --------------------------
 **Version**: unspecified
 **Severity**: enhancement
 **See Also**:
-URL","Medium",50,1429285347,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",2,NA,"[""Template search results list should contain each template's descripton."", ""**Author:** CODE\n\n**Description:**\nSee this feedback trhead: [ URL ]\n\nThe search results for parameters include each parameter's description, making it easy to select the right one."", ""But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template)."", 'So, add the template description to the search results list.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"**Author:** CODE\n\n**Description:**\nSee this feedback trhead: [ URL ]\n\nThe search results for parameters include each parameter's description, making it easy to select the right one."
-7678,"Template search results list should contain each template's descripton","**Author:** `turingt`
+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
 
-**Description:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+This will allow mere mortals to help identify bugs with unsupported browsers.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
+For option four, we can modify the blacklist, like so:
 
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
+JS> delete mw.libs.ve.blacklist.opera;
 
-So, add the template description to the search results list.
+But im not sure what to do after that.
 
 --------------------------
 **Version**: unspecified
 **Severity**: enhancement
 **See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=51774",1373980800,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_description","Template search results list should contain each template's descripton./n/n**Author:** `turingt`
+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
 
-**Description:**
-See this feedback trhead: [ https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Observation_-_Template_Editor_behavior_improved ]
+This will allow mere mortals to help identify bugs with unsupported browsers.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
+For option four, we can modify the blacklist, like so:
 
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
+JS> delete mw.libs.ve.blacklist.opera;
 
-So, add the template description to the search results list.
+But im not sure what to do after that.
 
 --------------------------
 **Version**: unspecified
 **Severity**: enhancement
 **See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=51774","Template search results list should contain each template's descripton./n/n**Author:** CODE
+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
 
-**Description:**
-See this feedback trhead: [ URL ]
+This will allow mere mortals to help identify bugs with unsupported browsers.
 
-The search results for parameters include each parameter's description, making it easy to select the right one. 
+For option four, we can modify the blacklist, like so:
 
-But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template).
+JS> delete mw.libs.ve.blacklist.opera;
 
-So, add the template description to the search results list.
+But im not sure what to do after that.
 
 --------------------------
 **Version**: unspecified
 **Severity**: enhancement
 **See Also**:
-URL","Medium",50,1429285347,"PHID-USER-ydswvwhh5pm4lshahjje","resolved","True","c1",3,"False","False",2,NA,"[""Template search results list should contain each template's descripton."", ""**Author:** CODE\n\n**Description:**\nSee this feedback trhead: [ URL ]\n\nThe search results for parameters include each parameter's description, making it easy to select the right one."", ""But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template)."", 'So, add the template description to the search results list.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement\n**See Also**:\nURL']",FALSE,0,"But the templates list result contains only the template name, even though the template description is available (it's shown right 'after' a template is selected, so it doesn't help in choosing the right template)."
-7679,"Template search results list should contain each template's descripton","Verified the fix in Betalabs",1429568922,"PHID-USER-24djtv3gj5gua2y6u2g5","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","Verified the fix in Betalabs","Verified the fix in Betalabs",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,94,NA,"['Verified the fix in Betalabs']",NA,0,"Verified the fix in Betalabs"
-7680,"Template search results list should contain each template's descripton","Change 203459 merged by jenkins-bot:
-Show template description in the template search
+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
 
-[[https://gerrit.wikimedia.org/r/203459]]",1429262905,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","Change 203459 merged by jenkins-bot:
-Show template description in the template search
+This will allow mere mortals to help identify bugs with unsupported browsers.
 
-[[https://gerrit.wikimedia.org/r/203459]]","Change 203459 merged by jenkins-bot:
-Show template description in the template search
+For option four, we can modify the blacklist, like so:
 
-[[GERRIT_URL]]",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,93,NA,"['Change 203459 merged by jenkins-bot:\nShow template description in the template search\n\n[[GERRIT_URL]]']",NA,0,"Change 203459 merged by jenkins-bot:\nShow template description in the template search\n\n[[GERRIT_URL]]"
-7681,"Template search results list should contain each template's descripton","Change 203459 had a related patch set uploaded (by Mooeypoo):
-Show template description in the template search
+JS> delete mw.libs.ve.blacklist.opera;
 
-[[https://gerrit.wikimedia.org/r/203459]]
-",1428697842,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","Change 203459 had a related patch set uploaded (by Mooeypoo):
-Show template description in the template search
+But im not sure what to do after that.
 
-[[https://gerrit.wikimedia.org/r/203459]]
-","Change 203459 had a related patch set uploaded (by Mooeypoo):
-Show template description in the template search
+--------------------------
+**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,92,NA,"['Change 203459 had a related patch set uploaded (by Mooeypoo):\nShow template description in the template search\n\n[[GERRIT_URL]]']",NA,0,"Change 203459 had a related patch set uploaded (by Mooeypoo):\nShow template description in the template search\n\n[[GERRIT_URL]]"
-7682,"Template search results list should contain each template's descripton","Thanks for the explanation, I've now reported it as bug 51822.",1374511823,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","Thanks for the explanation, I've now reported it as bug 51822.","Thanks for the explanation, I've now reported it as bug 51822.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""Thanks for the explanation, I've now reported it as bug 51822.""]",NA,0,"Thanks for the explanation, I've now reported it as bug 51822."
-7683,"Template search results list should contain each template's descripton","(In reply to comment #4)
-> (In reply to comment #3)
-> > > If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> > > functionality to be useful only for people who already know template names
-> > > (i.e. those who don't need it).
-> > 
-> > That is a distinct enhancement request; please open a new bug for it.
-> 
-> Is it distinct or is it part of bug 51670?
+",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
 
-It's distinct. This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.",1374509714,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","(In reply to comment #4)
-> (In reply to comment #3)
-> > > If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> > > functionality to be useful only for people who already know template names
-> > > (i.e. those who don't need it).
-> > 
-> > That is a distinct enhancement request; please open a new bug for it.
-> 
-> Is it distinct or is it part of bug 51670?
+[[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
 
-It's distinct. This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.","(In reply to comment #4)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-It's distinct. This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIt's distinct."", ""This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.""]",NA,0,"(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIt's distinct."
-7683,"Template search results list should contain each template's descripton","(In reply to comment #4)
-> (In reply to comment #3)
-> > > If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> > > functionality to be useful only for people who already know template names
-> > > (i.e. those who don't need it).
-> > 
-> > That is a distinct enhancement request; please open a new bug for it.
-> 
-> Is it distinct or is it part of bug 51670?
-
-It's distinct. This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.",1374509714,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","(In reply to comment #4)
-> (In reply to comment #3)
-> > > If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> > > functionality to be useful only for people who already know template names
-> > > (i.e. those who don't need it).
-> > 
-> > That is a distinct enhancement request; please open a new bug for it.
-> 
-> Is it distinct or is it part of bug 51670?
-
-It's distinct. This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.","(In reply to comment #4)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-It's distinct. This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"[""(In reply to comment #4)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIt's distinct."", ""This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion.""]",NA,0,"This is asking for VisualEditor when searching pages (for links), categories (for the category dialog) and templates (for the transclusion dialog) to use an entirely different (and slower) part of MediaWiki's search infrastructure so we can do in-string searching rather than left-string completion."
-7684,"Template search results list should contain each template's descripton","(In reply to comment #3)
-> > If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> > functionality to be useful only for people who already know template names
-> > (i.e. those who don't need it).
-> 
-> That is a distinct enhancement request; please open a new bug for it.
-
-Is it distinct or is it part of bug 51670?",1374508615,"PHID-USER-ysftv67jxeaxdwcakvwo","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","(In reply to comment #3)
-> > If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> > functionality to be useful only for people who already know template names
-> > (i.e. those who don't need it).
-> 
-> That is a distinct enhancement request; please open a new bug for it.
-
-Is it distinct or is it part of bug 51670?","(In reply to comment #3)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-Is it distinct or is it part of bug 51670?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIs it distinct or is it part of bug 51670?']",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nIs it distinct or is it part of bug 51670?"
-7685,"Template search results list should contain each template's descripton","(In reply to comment #2)
-> Also typing a word only shows template names starting with that word, not
-> containing it, which is a weird search behavior.
-> 
-> If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> functionality to be useful only for people who already know template names
-> (i.e. those who don't need it).
-
-That is a distinct enhancement request; please open a new bug for it.",1374507636,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","(In reply to comment #2)
-> Also typing a word only shows template names starting with that word, not
-> containing it, which is a weird search behavior.
-> 
-> If I type ""book"", template ""Cite book"" is not shown, which limits the search
-> functionality to be useful only for people who already know template names
-> (i.e. those who don't need it).
-
-That is a distinct enhancement request; please open a new bug for it.","(In reply to comment #2)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-That is a distinct enhancement request; please open a new bug for it.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"['(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is a distinct enhancement request; please open a new bug for it.']",NA,0,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThat is a distinct enhancement request; please open a new bug for it."
-7686,"Template search results list should contain each template's descripton","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).",1374502086,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['**turingt** wrote:\n\nAlso typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.', 'If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e.', ""those who don't need it).""]",NA,0,"**turingt** wrote:\n\nAlso typing a word only shows template names starting with that word, not containing it, which is a weird search behavior."
-7686,"Template search results list should contain each template's descripton","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).",1374502086,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['**turingt** wrote:\n\nAlso typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.', 'If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e.', ""those who don't need it).""]",NA,0,"If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e."
-7686,"Template search results list should contain each template's descripton","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).",1374502086,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).","**turingt** wrote:
-
-Also typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.
-
-If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e. those who don't need it).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['**turingt** wrote:\n\nAlso typing a word only shows template names starting with that word, not containing it, which is a weird search behavior.', 'If I type ""book"", template ""Cite book"" is not shown, which limits the search functionality to be useful only for people who already know template names (i.e.', ""those who don't need it).""]",NA,0,"those who don't need it)."
-7687,"Template search results list should contain each template's descripton","Also typing in 'new' into the New template box returns a list of 10 templates starting with 'new', with no way to scroll through the longer list of templates starting/containing with 'New'
-
-https://en.wikipedia.org/wiki/Special:PrefixIndex/Template:New
-
-More practical, 'New Zealand' or 'New York' only returns 10, and the user may not know the right keyword needed to return better results.",1374462543,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-3es7m4cbr63gg2w4l5or","task_subcomment","Also typing in 'new' into the New template box returns a list of 10 templates starting with 'new', with no way to scroll through the longer list of templates starting/containing with 'New'
-
-https://en.wikipedia.org/wiki/Special:PrefixIndex/Template:New
-
-More practical, 'New Zealand' or 'New York' only returns 10, and the user may not know the right keyword needed to return better results.","Also typing in 'new' into the New template box returns a list of 10 templates starting with 'new', with no way to scroll through the longer list of templates starting/containing with 'New'
-
-URL
-
-More practical, 'New Zealand' or 'New York' only returns 10, and the user may not know the right keyword needed to return better results.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"[""Also typing in 'new' into the New template box returns a list of 10 templates starting with 'new', with no way to scroll through the longer list of templates starting/containing with 'New'\n\nURL\n\nMore practical, 'New Zealand' or 'New York' only returns 10, and the user may not know the right keyword needed to return better results.""]",NA,0,"Also typing in 'new' into the New template box returns a list of 10 templates starting with 'new', with no way to scroll through the longer list of templates starting/containing with 'New'\n\nURL\n\nMore practical, 'New Zealand' or 'New York' only returns 10, and the user may not know the right keyword needed to return better results."
-8483,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","Try editing the professional ratings template in https://en.wikipedia.org/wiki/All_6%27s_and_7%27s?veaction=edit
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50551
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50910
-https://bugzilla.wikimedia.org/show_bug.cgi?id=51708",1372453440,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_description","VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it./n/nTry editing the professional ratings template in https://en.wikipedia.org/wiki/All_6%27s_and_7%27s?veaction=edit
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50551
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50910
-https://bugzilla.wikimedia.org/show_bug.cgi?id=51708","VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it./n/nTry editing the professional ratings template in URL
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-URL
-URL
-URL","Medium",50,1554826913,"PHID-USER-wkpnidxoctuhawexig5p","duplicate","True","c1",2,"False","False",-1,NA,"[""VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it."", 'Try editing the professional ratings template in URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL\nURL']",FALSE,0,"Try editing the professional ratings template in URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL\nURL"
-8483,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","Try editing the professional ratings template in https://en.wikipedia.org/wiki/All_6%27s_and_7%27s?veaction=edit
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50551
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50910
-https://bugzilla.wikimedia.org/show_bug.cgi?id=51708",1372453440,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_description","VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it./n/nTry editing the professional ratings template in https://en.wikipedia.org/wiki/All_6%27s_and_7%27s?veaction=edit
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50551
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50910
-https://bugzilla.wikimedia.org/show_bug.cgi?id=51708","VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it./n/nTry editing the professional ratings template in URL
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-URL
-URL
-URL","Medium",50,1554826913,"PHID-USER-wkpnidxoctuhawexig5p","duplicate","True","c1",2,"False","False",-1,NA,"[""VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it."", 'Try editing the professional ratings template in URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nURL\nURL\nURL']",FALSE,0,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it."
-8484,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","This issue also occurs for the following case:
-
-1.Add an image
-2.Add a gallery 
-3.Change the position of the image to the left 
-4.Select the gallery
-5.Try to select the image 
-
-Observed Result:
-Since the width of the phantom for the gallery is 100% , it is overlapping with the image and it becomes difficult to select the image after that.",1396302080,"PHID-USER-24djtv3gj5gua2y6u2g5","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","This issue also occurs for the following case:
-
-1.Add an image
-2.Add a gallery 
-3.Change the position of the image to the left 
-4.Select the gallery
-5.Try to select the image 
-
-Observed Result:
-Since the width of the phantom for the gallery is 100% , it is overlapping with the image and it becomes difficult to select the image after that.","This issue also occurs for the following case:
-
-1.Add an image
-2.Add a gallery 
-3.Change the position of the image to the left 
-4.Select the gallery
-5.Try to select the image 
-
-Observed Result:
-Since the width of the phantom for the gallery is 100% , it is overlapping with the image and it becomes difficult to select the image after that.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,39,NA,"['This issue also occurs for the following case:\n\n1.Add an image\n2.Add a gallery \n3.Change the position of the image to the left \n4.Select the gallery\n5.Try to select the image \n\nObserved Result:\nSince the width of the phantom for the gallery is 100% , it is overlapping with the image and it becomes difficult to select the image after that.']",NA,0,"This issue also occurs for the following case:\n\n1.Add an image\n2.Add a gallery \n3.Change the position of the image to the left \n4.Select the gallery\n5.Try to select the image \n\nObserved Result:\nSince the width of the phantom for the gallery is 100% , it is overlapping with the image and it becomes difficult to select the image after that."
-8485,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","*** Bug 51048 has been marked as a duplicate of this bug. ***",1385381652,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","*** Bug 51048 has been marked as a duplicate of this bug. ***","*** Bug 51048 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,21,NA,"['*** Bug 51048 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 51048 has been marked as a duplicate of this bug."
-8485,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","*** Bug 51048 has been marked as a duplicate of this bug. ***",1385381652,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","*** Bug 51048 has been marked as a duplicate of this bug. ***","*** Bug 51048 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,21,NA,"['*** Bug 51048 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-8486,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","*** Bug 50443 has been marked as a duplicate of this bug. ***",1377830806,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","*** Bug 50443 has been marked as a duplicate of this bug. ***","*** Bug 50443 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,8,NA,"['*** Bug 50443 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50443 has been marked as a duplicate of this bug."
-8486,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","*** Bug 50443 has been marked as a duplicate of this bug. ***",1377830806,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","*** Bug 50443 has been marked as a duplicate of this bug. ***","*** Bug 50443 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,8,NA,"['*** Bug 50443 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-8487,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","*** Bug 50211 has been marked as a duplicate of this bug. ***",1373164008,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","*** Bug 50211 has been marked as a duplicate of this bug. ***","*** Bug 50211 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"['*** Bug 50211 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50211 has been marked as a duplicate of this bug."
-8487,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","*** Bug 50211 has been marked as a duplicate of this bug. ***",1373164008,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","*** Bug 50211 has been marked as a duplicate of this bug. ***","*** Bug 50211 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"['*** Bug 50211 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-8488,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","Changed title to ""Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play. This can make it impossible to edit the floated item.",1372456631,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","Changed title to ""Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play. This can make it impossible to edit the floated item.","Changed title to ""Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play. This can make it impossible to edit the floated item.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['Changed title to ""Phantoms can be width:100% when the object they\'re meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play.', 'This can make it impossible to edit the floated item.']",NA,0,"Changed title to ""Phantoms can be width:100% when the object they\"
-8488,"VisualEditor: Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it","Changed title to ""Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play. This can make it impossible to edit the floated item.",1372456631,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-2r6x4q4bt3fqtg3es4ps","task_subcomment","Changed title to ""Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play. This can make it impossible to edit the floated item.","Changed title to ""Phantoms can be width:100% when the object they're meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play. This can make it impossible to edit the floated item.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-1,NA,"['Changed title to ""Phantoms can be width:100% when the object they\'re meant to cover has a floated element alongside it""; looks like the phantom is generated to be as wide as its target ""should"" be, before the floats come into play.', 'This can make it impossible to edit the floated item.']",NA,0,"; looks like the phantom is generated to be as wide as its target "
-8763,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","...and quite dramatically - take a look at https://en.wikipedia.org/w/index.php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-T50830",1371995700,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-vrnyctiie6ntzdrqt77a","task_description","VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff./n/n...and quite dramatically - take a look at https://en.wikipedia.org/w/index.php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-T50830","VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff./n/n...and quite dramatically - take a look at URL
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-T50830","Medium",50,1642380969,"PHID-USER-wkpnidxoctuhawexig5p","resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff.', '...and quite dramatically - take a look at URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nT50830']",FALSE,1,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff."
-8763,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","...and quite dramatically - take a look at https://en.wikipedia.org/w/index.php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-T50830",1371995700,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-vrnyctiie6ntzdrqt77a","task_description","VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff./n/n...and quite dramatically - take a look at https://en.wikipedia.org/w/index.php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-T50830","VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff./n/n...and quite dramatically - take a look at URL
-
---------------------------
-**Version**: unspecified
-**Severity**: normal
-**See Also**:
-T50830","Medium",50,1642380969,"PHID-USER-wkpnidxoctuhawexig5p","resolved","True","c1",2,"False","False",-2,NA,"['VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff.', '...and quite dramatically - take a look at URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nT50830']",FALSE,1,"...and quite dramatically - take a look at URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: normal\n**See Also**:\nT50830"
-8764,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","Parsoid's ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit. Please re-open if you run into similar dirty diffs that happened within the last year or so.",1642380969,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","Parsoid's ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit. Please re-open if you run into similar dirty diffs that happened within the last year or so.","Parsoid's ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit. Please re-open if you run into similar dirty diffs that happened within the last year or so.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,446,NA,"['Parsoid\'s ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit.', 'Please re-open if you run into similar dirty diffs that happened within the last year or so.']",NA,1,"Parsoid\"
-8764,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","Parsoid's ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit. Please re-open if you run into similar dirty diffs that happened within the last year or so.",1642380969,"PHID-USER-wkpnidxoctuhawexig5p","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","Parsoid's ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit. Please re-open if you run into similar dirty diffs that happened within the last year or so.","Parsoid's ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit. Please re-open if you run into similar dirty diffs that happened within the last year or so.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,446,NA,"['Parsoid\'s ""selective serialization"" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit.', 'Please re-open if you run into similar dirty diffs that happened within the last year or so.']",NA,1,"selective serialization"
-8765,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",1372000762,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.","(In reply to comment #0)
-QUOTE
-QUOTE
-QUOTE
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-QUOTE
-QUOTE
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh.', ""I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."", ""Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."", ""Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."", ':-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause.', '(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\'s going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can\'t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.']",NA,1,"(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh."
-8765,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",1372000762,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.","(In reply to comment #0)
-QUOTE
-QUOTE
-QUOTE
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-QUOTE
-QUOTE
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh.', ""I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."", ""Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."", ""Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."", ':-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause.', '(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\'s going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can\'t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.']",NA,1,":-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause."
-8765,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",1372000762,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.","(In reply to comment #0)
-QUOTE
-QUOTE
-QUOTE
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-QUOTE
-QUOTE
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh.', ""I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."", ""Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."", ""Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."", ':-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause.', '(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\'s going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can\'t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.']",NA,1,"(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\"
-8765,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",1372000762,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.","(In reply to comment #0)
-QUOTE
-QUOTE
-QUOTE
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-QUOTE
-QUOTE
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh.', ""I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."", ""Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."", ""Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."", ':-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause.', '(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\'s going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can\'t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.']",NA,1,"t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully."
-8765,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",1372000762,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.","(In reply to comment #0)
-QUOTE
-QUOTE
-QUOTE
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-QUOTE
-QUOTE
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh.', ""I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."", ""Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."", ""Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."", ':-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause.', '(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\'s going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can\'t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.']",NA,1,"I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."
-8765,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",1372000762,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.","(In reply to comment #0)
-QUOTE
-QUOTE
-QUOTE
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-QUOTE
-QUOTE
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh.', ""I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."", ""Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."", ""Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."", ':-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause.', '(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\'s going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can\'t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.']",NA,1,"Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."
-8765,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",1372000762,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","(In reply to comment #0)
-> ...and quite dramatically - take a look at
-> https://en.wikipedia.org/w/index.
-> php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-> Brad also has a suggestion (along with a bug report) for a workflow to make
-> these easier to identify:
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.","(In reply to comment #0)
-QUOTE
-QUOTE
-QUOTE
-
-Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.
-
-Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(
-
-Punting to Roan for thoughts, but I think this is probably a lost cause.
-
-(In reply to comment #1)
-QUOTE
-QUOTE
-
-That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-2,NA,"['(In reply to comment #0)\nQUOTE\nQUOTE\nQUOTE\n\nEurgh.', ""I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement."", ""Specifically, Foo Bar Baz is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these."", ""Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."", ':-(\n\nPunting to Roan for thoughts, but I think this is probably a lost cause.', '(In reply to comment #1)\nQUOTE\nQUOTE\n\nThat\'s going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can\'t objectively know what bits of the DOM it ""should"" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.']",NA,1,"Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen."
-8766,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",1371996216,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-2,NA,"['Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:\n\n""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff.', ""If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team."", '(Please don\'t try to use this idea as an error concealment technique: these errors shouldn\'t occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""']",NA,1,"Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:\n\n""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff."
-8766,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",1371996216,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-2,NA,"['Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:\n\n""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff.', ""If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team."", '(Please don\'t try to use this idea as an error concealment technique: these errors shouldn\'t occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""']",NA,1,"(Please don\"
-8766,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",1371996216,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-2,NA,"['Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:\n\n""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff.', ""If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team."", '(Please don\'t try to use this idea as an error concealment technique: these errors shouldn\'t occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""']",NA,1,"t occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)"""
-8766,"VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",1371996216,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-vrnyctiie6ntzdrqt77a","task_subcomment","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""","Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:
-
-""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""",NA,NA,NA,NA,NA,"True","c1",2,"False",NA,-2,NA,"['Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:\n\n""One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff.', ""If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team."", '(Please don\'t try to use this idea as an error concealment technique: these errors shouldn\'t occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)""']",NA,1,"If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team."
-9354,"Parsoid should support  and  natively as they are not normal parser tags","screenshot
-
-Example: https://www.mediawiki.org/wiki/Communication
-
---------------------------
-**Version**: unspecified
-**Severity**: major
-**URL**: http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50284
-
-**Attached**: {F10855}",1369744440,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_description","Parsoid should support  and  natively as they are not normal parser tags./n/nscreenshot
-
-Example: https://www.mediawiki.org/wiki/Communication
-
---------------------------
-**Version**: unspecified
-**Severity**: major
-**URL**: http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50284
-
-**Attached**: {F10855}","Parsoid should support  and  natively as they are not normal parser tags./n/nscreenshot
-
-Example: URL
-
---------------------------
-**Version**: unspecified
-**Severity**: major
-**URL**: URL
-**See Also**:
-URL
-
-**Attached**: {F10855}","Medium",50,1451432369,"PHID-USER-gxcjmjpejlhfnrquksm2","resolved","True","c1",1,"True","False",-5,NA,"['Parsoid should support  and  natively as they are not normal parser tags.', 'screenshot\n\nExample: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major\n**URL**: URL\n**See Also**:\nURL\n\n**Attached**: {F10855}']",FALSE,0,"Parsoid should support  and  natively as they are not normal parser tags."
-9354,"Parsoid should support  and  natively as they are not normal parser tags","screenshot
-
-Example: https://www.mediawiki.org/wiki/Communication
-
---------------------------
-**Version**: unspecified
-**Severity**: major
-**URL**: http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50284
-
-**Attached**: {F10855}",1369744440,"PHID-USER-wrimmmr5w2zt7nk2t753","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_description","Parsoid should support  and  natively as they are not normal parser tags./n/nscreenshot
-
-Example: https://www.mediawiki.org/wiki/Communication
-
---------------------------
-**Version**: unspecified
-**Severity**: major
-**URL**: http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=50284
-
-**Attached**: {F10855}","Parsoid should support  and  natively as they are not normal parser tags./n/nscreenshot
-
-Example: URL
-
---------------------------
-**Version**: unspecified
-**Severity**: major
-**URL**: URL
-**See Also**:
-URL
-
-**Attached**: {F10855}","Medium",50,1451432369,"PHID-USER-gxcjmjpejlhfnrquksm2","resolved","True","c1",1,"True","False",-5,NA,"['Parsoid should support  and  natively as they are not normal parser tags.', 'screenshot\n\nExample: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major\n**URL**: URL\n**See Also**:\nURL\n\n**Attached**: {F10855}']",FALSE,0,"screenshot\n\nExample: URL\n\n--------------------------\n**Version**: unspecified\n**Severity**: major\n**URL**: URL\n**See Also**:\nURL\n\n**Attached**: {F10855}"
-9355,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid will now wrap these appropriately with the proper typeof `mw:Extension/translate` and whatnot.
-
-Support for the Translate extension in VE is still needed, but a separate task.",1451432369,"PHID-USER-gxcjmjpejlhfnrquksm2","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid will now wrap these appropriately with the proper typeof `mw:Extension/translate` and whatnot.
-
-Support for the Translate extension in VE is still needed, but a separate task.","Parsoid will now wrap these appropriately with the proper typeof CODE and whatnot.
-
-Support for the Translate extension in VE is still needed, but a separate task.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,130,NA,"['Parsoid will now wrap these appropriately with the proper typeof CODE and whatnot.', 'Support for the Translate extension in VE is still needed, but a separate task.']",NA,0,"Parsoid will now wrap these appropriately with the proper typeof CODE and whatnot."
-9355,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid will now wrap these appropriately with the proper typeof `mw:Extension/translate` and whatnot.
-
-Support for the Translate extension in VE is still needed, but a separate task.",1451432369,"PHID-USER-gxcjmjpejlhfnrquksm2","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid will now wrap these appropriately with the proper typeof `mw:Extension/translate` and whatnot.
-
-Support for the Translate extension in VE is still needed, but a separate task.","Parsoid will now wrap these appropriately with the proper typeof CODE and whatnot.
-
-Support for the Translate extension in VE is still needed, but a separate task.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,130,NA,"['Parsoid will now wrap these appropriately with the proper typeof CODE and whatnot.', 'Support for the Translate extension in VE is still needed, but a separate task.']",NA,0,"Support for the Translate extension in VE is still needed, but a separate task."
-9356,"Parsoid should support  and  natively as they are not normal parser tags","Change 261293 merged by jenkins-bot:
-T50891: Register  and  natively
-
-[[https://gerrit.wikimedia.org/r/261293]]",1451423865,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 261293 merged by jenkins-bot:
-T50891: Register  and  natively
-
-[[https://gerrit.wikimedia.org/r/261293]]","Change 261293 merged by jenkins-bot:
-T50891: Register  and  natively
-
-[[GERRIT_URL]]",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,130,NA,"['Change 261293 merged by jenkins-bot:\nT50891: Register  and  natively\n\n[[GERRIT_URL]]']",NA,0,"Change 261293 merged by jenkins-bot:\nT50891: Register  and  natively\n\n[[GERRIT_URL]]"
-9357,"Parsoid should support  and  natively as they are not normal parser tags","Change 261293 had a related patch set uploaded (by Arlolra):
-T50891: Register  and  natively
-
-[[https://gerrit.wikimedia.org/r/261293]]
-",1451345650,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 261293 had a related patch set uploaded (by Arlolra):
-T50891: Register  and  natively
-
-[[https://gerrit.wikimedia.org/r/261293]]
-","Change 261293 had a related patch set uploaded (by Arlolra):
-T50891: Register  and  natively
+[[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,130,NA,"['Change 261293 had a related patch set uploaded (by Arlolra):\nT50891: Register  and  natively\n\n[[GERRIT_URL]]']",NA,0,"Change 261293 had a related patch set uploaded (by Arlolra):\nT50891: Register  and  natively\n\n[[GERRIT_URL]]"
-9358,"Parsoid should support  and  natively as they are not normal parser tags",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+",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
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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).
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",1449004296,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+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
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.","QUOTE
 QUOTE
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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.
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,126,NA,"['QUOTE\nQUOTE\n\nA generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions.', 'As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated.', 'VE and other tools can then use this to provide translation support by querying the API to manage translations.', 'I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.']",NA,0,"QUOTE\nQUOTE\n\nA generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions."
-9358,"Parsoid should support  and  natively as they are not normal parser tags",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+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.
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",1449004296,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+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.
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.","QUOTE
 QUOTE
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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.
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,126,NA,"['QUOTE\nQUOTE\n\nA generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions.', 'As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated.', 'VE and other tools can then use this to provide translation support by querying the API to manage translations.', 'I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.']",NA,0,"As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated."
-9358,"Parsoid should support  and  natively as they are not normal parser tags",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+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.
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",1449004296,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+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.
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.","QUOTE
 QUOTE
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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.
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,126,NA,"['QUOTE\nQUOTE\n\nA generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions.', 'As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated.', 'VE and other tools can then use this to provide translation support by querying the API to manage translations.', 'I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.']",NA,0,"VE and other tools can then use this to provide translation support by querying the API to manage translations."
-9358,"Parsoid should support  and  natively as they are not normal parser tags",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+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.
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",1449004296,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment",">>! In T50891#1840365, @kaldari wrote:
-> Any update on this?
+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.
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.","QUOTE
 QUOTE
 
-A generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions. As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated. VE and other tools can then use this to provide translation support by querying the API to manage translations.
+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.
 
-I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,126,NA,"['QUOTE\nQUOTE\n\nA generic extension registration mechanism in Parsoid is one of our (parsing team) goals for this quarter and once that is done, we should be able to work on specific extensions.', 'As noted in T50891#1002436, I think we can implement a parsoid-native version of this which adds annotations to the DOM that marks trees that need to be translated.', 'VE and other tools can then use this to provide translation support by querying the API to manage translations.', 'I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on.']",NA,0,"I think we can get the extension part done within the next month or so, but the tools to build on top of that is something for VE and language team to work on."
-9359,"Parsoid should support  and  natively as they are not normal parser tags","Any update on this?",1448940120,"PHID-USER-a5pveeqqwaddgfjiv2fq","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Any update on this?","Any update on this?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,126,NA,"['Any update on this?']",NA,0,"Any update on this?"
-9360,"Parsoid should support  and  natively as they are not normal parser tags","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
+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.
 
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
+>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)
 
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",1422567418,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
+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 native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
+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.
 
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
+>Reference incidences (s) inside templates are an entirely distinct problem for VisualEditor to worry about, and this isn't about that. :-)
 
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
+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 should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"[""Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension)."", 'This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation.', 'In addition, it would also have to register a html2wt handler for serializing it back to wikitext.', 'This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does.', 'Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.']",NA,0,"This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation."
-9360,"Parsoid should support  and  natively as they are not normal parser tags","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
+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
 
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",1422567418,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"[""Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension)."", 'This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation.', 'In addition, it would also have to register a html2wt handler for serializing it back to wikitext.', 'This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does.', 'Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.']",NA,0,"In addition, it would also have to register a html2wt handler for serializing it back to wikitext."
-9360,"Parsoid should support  and  natively as they are not normal parser tags","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",1422567418,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"[""Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension)."", 'This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation.', 'In addition, it would also have to register a html2wt handler for serializing it back to wikitext.', 'This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does.', 'Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.']",NA,0,"This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does."
-9360,"Parsoid should support  and  natively as they are not normal parser tags","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",1422567418,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"[""Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension)."", 'This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation.', 'In addition, it would also have to register a html2wt handler for serializing it back to wikitext.', 'This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does.', 'Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.']",NA,0,"Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months."
-9360,"Parsoid should support  and  natively as they are not normal parser tags","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",1422567418,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.","Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension).
-
-This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation. In addition, it would also have to register a html2wt handler for serializing it back to wikitext.
-
-This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does. Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"[""Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension)."", 'This native translate will be relatively straightforward and will not do anything special beyond recognizing the  and associated tags and marking up DOM fragments with a special typeof that clients like VE or gadgets or anyone could use to enable translation.', 'In addition, it would also have to register a html2wt handler for serializing it back to wikitext.', 'This should not be a lot of work -- most of it will be in figuring out if there are any tricky things that the translate extension does.', 'Talking to Niklas, we figured this is not high priority, but something worth tackling over the next 6 months.']",NA,0,"Since  is a special extension that hooks into the parser pipeline in a way that is not visible to Parsoid, and also since it doesn't render anything new, but marks DOM fragments for translation, the ideal way to deal with this in the short term (till translation goes with a VE based approach) is to implement a native version of translate in Parsoid (just like Cite and planned Gallery extension)."
-9361,"Parsoid should support  and  natively as they are not normal parser tags","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",1422482506,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"['I had a chat with Subbu about this.', 'In the short tem (this year) we could add configurable support for  tags in parsoid.', 'That support will preserve the tags and comments when pages are edited with VE.', 'In the long term we will implement support for translatable pages without any kind of markup.', 'Marking those pages for translation would only work with VE and it needs special page translation module in VE.']",NA,0,"I had a chat with Subbu about this."
-9361,"Parsoid should support  and  natively as they are not normal parser tags","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",1422482506,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"['I had a chat with Subbu about this.', 'In the short tem (this year) we could add configurable support for  tags in parsoid.', 'That support will preserve the tags and comments when pages are edited with VE.', 'In the long term we will implement support for translatable pages without any kind of markup.', 'Marking those pages for translation would only work with VE and it needs special page translation module in VE.']",NA,0,"In the short tem (this year) we could add configurable support for  tags in parsoid."
-9361,"Parsoid should support  and  natively as they are not normal parser tags","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",1422482506,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"['I had a chat with Subbu about this.', 'In the short tem (this year) we could add configurable support for  tags in parsoid.', 'That support will preserve the tags and comments when pages are edited with VE.', 'In the long term we will implement support for translatable pages without any kind of markup.', 'Marking those pages for translation would only work with VE and it needs special page translation module in VE.']",NA,0,"That support will preserve the tags and comments when pages are edited with VE."
-9361,"Parsoid should support  and  natively as they are not normal parser tags","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",1422482506,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"['I had a chat with Subbu about this.', 'In the short tem (this year) we could add configurable support for  tags in parsoid.', 'That support will preserve the tags and comments when pages are edited with VE.', 'In the long term we will implement support for translatable pages without any kind of markup.', 'Marking those pages for translation would only work with VE and it needs special page translation module in VE.']",NA,0,"In the long term we will implement support for translatable pages without any kind of markup."
-9361,"Parsoid should support  and  natively as they are not normal parser tags","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",1422482506,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.","I had a chat with Subbu about this. In the short tem (this year) we could add configurable support for  tags in parsoid. That support will preserve the tags and comments when pages are edited with VE. In the long term we will implement support for translatable pages without any kind of markup. Marking those pages for translation would only work with VE and it needs special page translation module in VE.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,82,NA,"['I had a chat with Subbu about this.', 'In the short tem (this year) we could add configurable support for  tags in parsoid.', 'That support will preserve the tags and comments when pages are edited with VE.', 'In the long term we will implement support for translatable pages without any kind of markup.', 'Marking those pages for translation would only work with VE and it needs special page translation module in VE.']",NA,0,"Marking those pages for translation would only work with VE and it needs special page translation module in VE."
-9362,"Parsoid should support  and  natively as they are not normal parser tags","Kabhi2104 asked on #mediawiki-i18n:
-> Nemo_bis:  i had one doubt, what does normal parser tags mean ?
-
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[https://www.mediawiki.org/wiki/Special:Version|the list on Special:Version]].
-
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[https://meta.wikimedia.org/wiki/Help_talk:List#List-agnostic_markup_insertions|is meaningful for the parser and perhaps shouldn't be required]].
-
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.",1422112321,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Kabhi2104 asked on #mediawiki-i18n:
-> Nemo_bis:  i had one doubt, what does normal parser tags mean ?
-
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[https://www.mediawiki.org/wiki/Special:Version|the list on Special:Version]].
-
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[https://meta.wikimedia.org/wiki/Help_talk:List#List-agnostic_markup_insertions|is meaningful for the parser and perhaps shouldn't be required]].
-
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.","Kabhi2104 asked on #mediawiki-i18n:
 QUOTE
 
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[URL list on Special:Version]].
+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.
 
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[URL meaningful for the parser and perhaps shouldn't be required]].
+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.
 
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,81,NA,"['Kabhi2104 asked on #mediawiki-i18n:\nQUOTE\n\nExplained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn\'t know"" it.', 'A symptom is the absence from [[URL list on Special:Version]].', 'Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894.', ""But even in the current situation there are some limitations, especially for the newline, which [[URL meaningful for the parser and perhaps shouldn't be required]]."", ""More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.""]",NA,0,"Kabhi2104 asked on #mediawiki-i18n:\nQUOTE\n\nExplained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn\"
-9362,"Parsoid should support  and  natively as they are not normal parser tags","Kabhi2104 asked on #mediawiki-i18n:
-> Nemo_bis:  i had one doubt, what does normal parser tags mean ?
+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.
 
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[https://www.mediawiki.org/wiki/Special:Version|the list on Special:Version]].
+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.
 
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[https://meta.wikimedia.org/wiki/Help_talk:List#List-agnostic_markup_insertions|is meaningful for the parser and perhaps shouldn't be required]].
+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.
 
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.",1422112321,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Kabhi2104 asked on #mediawiki-i18n:
-> Nemo_bis:  i had one doubt, what does normal parser tags mean ?
+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).
 
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[https://www.mediawiki.org/wiki/Special:Version|the list on Special:Version]].
+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.
 
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[https://meta.wikimedia.org/wiki/Help_talk:List#List-agnostic_markup_insertions|is meaningful for the parser and perhaps shouldn't be required]].
+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.
 
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.","Kabhi2104 asked on #mediawiki-i18n:
-QUOTE
+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.
 
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[URL list on Special:Version]].
 
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[URL meaningful for the parser and perhaps shouldn't be required]].
+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.
 
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,81,NA,"['Kabhi2104 asked on #mediawiki-i18n:\nQUOTE\n\nExplained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn\'t know"" it.', 'A symptom is the absence from [[URL list on Special:Version]].', 'Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894.', ""But even in the current situation there are some limitations, especially for the newline, which [[URL meaningful for the parser and perhaps shouldn't be required]]."", ""More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.""]",NA,0,"t be required]]."", ""More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don"
-9362,"Parsoid should support  and  natively as they are not normal parser tags","Kabhi2104 asked on #mediawiki-i18n:
-> Nemo_bis:  i had one doubt, what does normal parser tags mean ?
+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.
 
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[https://www.mediawiki.org/wiki/Special:Version|the list on Special:Version]].
+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.
 
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[https://meta.wikimedia.org/wiki/Help_talk:List#List-agnostic_markup_insertions|is meaningful for the parser and perhaps shouldn't be required]].
+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.
 
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.",1422112321,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Kabhi2104 asked on #mediawiki-i18n:
-> Nemo_bis:  i had one doubt, what does normal parser tags mean ?
+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).
 
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[https://www.mediawiki.org/wiki/Special:Version|the list on Special:Version]].
+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.
 
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[https://meta.wikimedia.org/wiki/Help_talk:List#List-agnostic_markup_insertions|is meaningful for the parser and perhaps shouldn't be required]].
+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.
 
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.","Kabhi2104 asked on #mediawiki-i18n:
-QUOTE
+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.
 
-Explained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn't know"" it. A symptom is the absence from [[URL list on Special:Version]].
 
-Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894. But even in the current situation there are some limitations, especially for the newline, which [[URL meaningful for the parser and perhaps shouldn't be required]].
+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.
 
-More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,81,NA,"['Kabhi2104 asked on #mediawiki-i18n:\nQUOTE\n\nExplained briefly from a non-technical perspective, this means that  is a ""tag"" for the Translate extension, but the parser ""doesn\'t know"" it.', 'A symptom is the absence from [[URL list on Special:Version]].', 'Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894.', ""But even in the current situation there are some limitations, especially for the newline, which [[URL meaningful for the parser and perhaps shouldn't be required]]."", ""More broadly, one could speculate that most wikitext markup is meant to add or modify the HTML of the resulting page, or properties of the page in the database: while translate tags don't do either and are properties of the wikitext itself.""]",NA,0," it.', 'A symptom is the absence from [[URL list on Special:Version]].', 'Concretely, the parser deals with tags in ways that interfere with the Translate syntax, with some consequences identified in T50891#524894.', "
-9363,"Parsoid should support  and  natively as they are not normal parser tags","To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself. I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.",1412577526,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself. I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.","To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself. I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself."", 'I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.']",NA,0,"I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid."
-9363,"Parsoid should support  and  natively as they are not normal parser tags","To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself. I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.",1412577526,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself. I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.","To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself. I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,66,NA,"[""To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself."", 'I cannot continue with this patch/bug until I get help from other people to modify parser/parsoid.']",NA,0,"To be clear: there is nothing wrong with that patch itself, it just doesn't work due to limitations in the parser itself."
-9364,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to Nemo from comment #43)
-> (In reply to James Forrester from comment #42)
-> > No patch any more. :-(
-> 
-> Hmm I'm not sure that's what ""Can be re-activated if there is outlook on
-> getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible
-> way to tag such stale patches in need of TLC.
+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.
 
-No. There is no patch to review for merge. There is patch to re-*do*.",1399802210,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to Nemo from comment #43)
-> (In reply to James Forrester from comment #42)
-> > No patch any more. :-(
-> 
-> Hmm I'm not sure that's what ""Can be re-activated if there is outlook on
-> getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible
-> way to tag such stale patches in need of TLC.
+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.
 
-No. There is no patch to review for merge. There is patch to re-*do*.","(In reply to Nemo from comment #43)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
+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.
 
-No. There is no patch to review for merge. There is patch to re-*do*.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,44,NA,"['(In reply to Nemo from comment #43)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nNo.', 'There is no patch to review for merge.', 'There is patch to re-*do*.']",NA,0,"(In reply to Nemo from comment #43)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nNo."
-9364,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to Nemo from comment #43)
-> (In reply to James Forrester from comment #42)
-> > No patch any more. :-(
-> 
-> Hmm I'm not sure that's what ""Can be re-activated if there is outlook on
-> getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible
-> way to tag such stale patches in need of TLC.
+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).
 
-No. There is no patch to review for merge. There is patch to re-*do*.",1399802210,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to Nemo from comment #43)
-> (In reply to James Forrester from comment #42)
-> > No patch any more. :-(
-> 
-> Hmm I'm not sure that's what ""Can be re-activated if there is outlook on
-> getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible
-> way to tag such stale patches in need of TLC.
+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.
 
-No. There is no patch to review for merge. There is patch to re-*do*.","(In reply to Nemo from comment #43)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
+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.
 
-No. There is no patch to review for merge. There is patch to re-*do*.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,44,NA,"['(In reply to Nemo from comment #43)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nNo.', 'There is no patch to review for merge.', 'There is patch to re-*do*.']",NA,0,"There is no patch to review for merge."
-9364,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to Nemo from comment #43)
-> (In reply to James Forrester from comment #42)
-> > No patch any more. :-(
-> 
-> Hmm I'm not sure that's what ""Can be re-activated if there is outlook on
-> getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible
-> way to tag such stale patches in need of TLC.
+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.
 
-No. There is no patch to review for merge. There is patch to re-*do*.",1399802210,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to Nemo from comment #43)
-> (In reply to James Forrester from comment #42)
-> > No patch any more. :-(
-> 
-> Hmm I'm not sure that's what ""Can be re-activated if there is outlook on
-> getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible
-> way to tag such stale patches in need of TLC.
 
-No. There is no patch to review for merge. There is patch to re-*do*.","(In reply to Nemo from comment #43)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
+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.
 
-No. There is no patch to review for merge. There is patch to re-*do*.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,44,NA,"['(In reply to Nemo from comment #43)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nNo.', 'There is no patch to review for merge.', 'There is patch to re-*do*.']",NA,0,"There is patch to re-*do*."
-9365,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to James Forrester from comment #42)
-> No patch any more. :-(
+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.
 
-Hmm I'm not sure that's what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.",1399802137,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to James Forrester from comment #42)
-> No patch any more. :-(
+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.
 
-Hmm I'm not sure that's what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.","(In reply to James Forrester from comment #42)
-QUOTE
+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.
 
-Hmm I'm not sure that's what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,44,NA,"['(In reply to James Forrester from comment #42)\nQUOTE\n\nHmm I\'m not sure that\'s what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.']",NA,0,"(In reply to James Forrester from comment #42)\nQUOTE\n\nHmm I\"
-9365,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to James Forrester from comment #42)
-> No patch any more. :-(
+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).
 
-Hmm I'm not sure that's what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.",1399802137,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to James Forrester from comment #42)
-> No patch any more. :-(
+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.
 
-Hmm I'm not sure that's what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.","(In reply to James Forrester from comment #42)
-QUOTE
+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.
 
-Hmm I'm not sure that's what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,44,NA,"['(In reply to James Forrester from comment #42)\nQUOTE\n\nHmm I\'m not sure that\'s what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC.']",NA,0,"s what ""Can be re-activated if there is outlook on getting this in a mergable state"" means, PATCH_TO_REVIEW seems a sensible way to tag such stale patches in need of TLC."
-9366,"Parsoid should support  and  natively as they are not normal parser tags","No patch any more. :-(",1399715908,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","No patch any more. :-(","No patch any more. :-(",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,44,NA,"['No patch any more.', ':-(']",NA,0,"No patch any more."
-9366,"Parsoid should support  and  natively as they are not normal parser tags","No patch any more. :-(",1399715908,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","No patch any more. :-(","No patch any more. :-(",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,44,NA,"['No patch any more.', ':-(']",NA,0,":-("
-9367,"Parsoid should support  and  natively as they are not normal parser tags","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+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:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+ok done
 
-https://gerrit.wikimedia.org/r/91583",1397663477,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+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:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+ok done
 
-https://gerrit.wikimedia.org/r/91583","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+https://gerrit.wikimedia.org/r/123105","Change 123105 abandoned by Alex Monk:
+Support new column-width and list-style attributes to Cite's 
 
 Reason:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+ok done
 
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['Change 91583 abandoned by Siebrand:\nAdd $wgTranslatePageTranslationUseParserHook\n\nReason:\nAbandoned as there is no progress on this patch set.', 'Can be re-activated if there is outlook on getting this in a mergable state.', 'GERRIT_URL']",NA,0,"Change 91583 abandoned by Siebrand:\nAdd $wgTranslatePageTranslationUseParserHook\n\nReason:\nAbandoned as there is no progress on this patch set."
-9367,"Parsoid should support  and  natively as they are not normal parser tags","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+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:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+Restoring so I can do a rebase to get the VE patch working
 
-https://gerrit.wikimedia.org/r/91583",1397663477,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+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:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+Restoring so I can do a rebase to get the VE patch working
 
-https://gerrit.wikimedia.org/r/91583","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+https://gerrit.wikimedia.org/r/123105","Change 123105 restored by Alex Monk:
+Support new column-width and list-style attributes to Cite's 
 
 Reason:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+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,41,NA,"['Change 91583 abandoned by Siebrand:\nAdd $wgTranslatePageTranslationUseParserHook\n\nReason:\nAbandoned as there is no progress on this patch set.', 'Can be re-activated if there is outlook on getting this in a mergable state.', 'GERRIT_URL']",NA,0,"Can be re-activated if there is outlook on getting this in a mergable state."
-9367,"Parsoid should support  and  natively as they are not normal parser tags","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+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:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+Going to use classes.
 
-https://gerrit.wikimedia.org/r/91583",1397663477,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+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:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+Going to use classes.
 
-https://gerrit.wikimedia.org/r/91583","Change 91583 abandoned by Siebrand:
-Add $wgTranslatePageTranslationUseParserHook
+https://gerrit.wikimedia.org/r/120962","Change 120962 restored by Alex Monk:
+Support setting column-width and list-style in  tag
 
 Reason:
-Abandoned as there is no progress on this patch set. Can be re-activated if there is outlook on getting this in a mergable state.
+Going to use classes.
 
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,41,NA,"['Change 91583 abandoned by Siebrand:\nAdd $wgTranslatePageTranslationUseParserHook\n\nReason:\nAbandoned as there is no progress on this patch set.', 'Can be re-activated if there is outlook on getting this in a mergable state.', 'GERRIT_URL']",NA,0,"GERRIT_URL"
-9368,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
+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).
 > > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
+> > 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.
 > 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
-
+> 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.
 > 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
+> 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.
 > 
-> Can you check whether your headings are matched by the formatHeadings regexp?
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-> 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
-
-Any changes for interim solutions?",1382781712,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
+> (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).
 > > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
+> > 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.
 > 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
-
+> 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.
 > 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
+> 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).
 > 
-> Can you check whether your headings are matched by the formatHeadings regexp?
+> 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.
 
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

+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.
 
-Not sure whether that matches or not.
+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).
 > 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
+> 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.
 
-Any changes for interim solutions?","(In reply to comment #39)
-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. 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
@@ -16927,449 +19917,293 @@ QUOTE
 QUOTE
 QUOTE
 
-This causes (lack of) whitespace issues and breaks all lists.
+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.
 
-QUOTE
-QUOTE
+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.
 
-It doesn't.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-Any changes for interim solutions?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['(In reply to comment #39)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis causes (lack of) whitespace issues and breaks all lists.', ""QUOTE\nQUOTE\n\nIt doesn't."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI\'m assuming it processes the html I\'m returning, which is:\n
CultureCulture
\n\nNot sure whether that matches or not.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAny changes for interim solutions?']",NA,0,"(In reply to comment #39)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis causes (lack of) whitespace issues and breaks all lists."
-9368,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
+(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).
 > 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
+> 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.
 
-This causes (lack of) whitespace issues and breaks all lists.
+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.
 
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
+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).
 > 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
+> 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).
 > 
-> Can you check whether your headings are matched by the formatHeadings regexp?
+> 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.
 
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

+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.
 
-Not sure whether that matches or not.
+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).
 > 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
+> 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.
 
-Any changes for interim solutions?",1382781712,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
+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).
 > 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
+> 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.
 
-This causes (lack of) whitespace issues and breaks all lists.
+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.
 
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
+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).
 > 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
+> 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)
 > 
-> Can you check whether your headings are matched by the formatHeadings regexp?
+> ""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).
 
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
+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)
 > 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
+> 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).
 
-Any changes for interim solutions?","(In reply to comment #39)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-QUOTE
-QUOTE
-
-It doesn't.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-Any changes for interim solutions?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['(In reply to comment #39)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis causes (lack of) whitespace issues and breaks all lists.', ""QUOTE\nQUOTE\n\nIt doesn't."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI\'m assuming it processes the html I\'m returning, which is:\n
CultureCulture
\n\nNot sure whether that matches or not.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAny changes for interim solutions?']",NA,0,"QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI\"
-9368,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
+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)
 > 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
+> ""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).
 
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
+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)
 > 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
+> 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)
 > 
-> Can you check whether your headings are matched by the formatHeadings regexp?
+> ""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).
 
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
+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)
 > 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
+> 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).
 
-Any changes for interim solutions?",1382781712,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
+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)
 > 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
+> ""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).
 
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
+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)
 > 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
+> 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)
 > 
-> Can you check whether your headings are matched by the formatHeadings regexp?
+> ""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).
 
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
+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)
 > 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
+> 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).
 
-Any changes for interim solutions?","(In reply to comment #39)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-QUOTE
-QUOTE
-
-It doesn't.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-Any changes for interim solutions?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['(In reply to comment #39)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis causes (lack of) whitespace issues and breaks all lists.', ""QUOTE\nQUOTE\n\nIt doesn't."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI\'m assuming it processes the html I\'m returning, which is:\n
CultureCulture
\n\nNot sure whether that matches or not.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAny changes for interim solutions?']",NA,0,"m returning, which is:\n
CultureCulture
\n\nNot sure whether that matches or not."
-9368,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
+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)
 > 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
+> ""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).
 
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
+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)
 > 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
-> 
-> Can you check whether your headings are matched by the formatHeadings regexp?
+> 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).
 
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-> 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
-
-Any changes for interim solutions?",1382781712,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
-> 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
-
-> 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
-> 
-> Can you check whether your headings are matched by the formatHeadings regexp?
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-> 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
-
-Any changes for interim solutions?","(In reply to comment #39)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-QUOTE
-QUOTE
-
-It doesn't.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-Any changes for interim solutions?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['(In reply to comment #39)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis causes (lack of) whitespace issues and breaks all lists.', ""QUOTE\nQUOTE\n\nIt doesn't."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI\'m assuming it processes the html I\'m returning, which is:\n
CultureCulture
\n\nNot sure whether that matches or not.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAny changes for interim solutions?']",NA,0,"QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAny changes for interim solutions?"
-9368,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
-> 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
-
-> 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
-> 
-> Can you check whether your headings are matched by the formatHeadings regexp?
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-> 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
-
-Any changes for interim solutions?",1382781712,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #39)
-> (In reply to comment #36)
-> > Issues I have found:
-> > 
-> > * [MAJOR] Disabling edit section links does not work for headings inside
-> >  tags
-> 
-> You could try marking your output as HTML according to
-> https://www.mediawiki.org/wiki/Manual:
-> Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.
-> 3F
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-> I'm not sure whether that suppresses section edit links too, but worth a try
-> IMO.
-
-It doesn't.
-
-> 
-> > * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> > fix. Above issue make this a bigger issue.
-> > * [BLOCKER] Table of contents does not include links
-> 
-> Can you check whether your headings are matched by the formatHeadings regexp?
-
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

-
-Not sure whether that matches or not.
-
-> 
-> Ideally we'd move both TOC and section edit links to JS / CSS. That is our
-> plan
-> for Parsoid output, but not going to happen over night.
-
-Any changes for interim solutions?","(In reply to comment #39)
-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"".","(In reply to comment #1)
 QUOTE
-QUOTE
-QUOTE
-
-This causes (lack of) whitespace issues and breaks all lists.
-
-QUOTE
-QUOTE
-
-It doesn't.
-
 QUOTE
 QUOTE
 QUOTE
@@ -17377,8029 +20211,5874 @@ QUOTE
 QUOTE
 QUOTE
 
-I'm assuming it processes the html I'm returning, which is:
-
CultureCulture

+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.
 
-Not sure whether that matches or not.
-
-QUOTE
-QUOTE
-QUOTE
 QUOTE
-
-Any changes for interim solutions?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['(In reply to comment #39)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nThis causes (lack of) whitespace issues and breaks all lists.', ""QUOTE\nQUOTE\n\nIt doesn't."", 'QUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nI\'m assuming it processes the html I\'m returning, which is:\n
CultureCulture
\n\nNot sure whether that matches or not.', 'QUOTE\nQUOTE\nQUOTE\nQUOTE\n\nAny changes for interim solutions?']",NA,0,"QUOTE\nQUOTE\n\nIt doesn't."
-9369,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
-
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
-
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
-
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
-
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",1382742193,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
-
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
-
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
-
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
-
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.","(In reply to comment #36)
 QUOTE
 QUOTE
 QUOTE
 QUOTE
-
-You could try marking your output as HTML according to URL
-
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
-
 QUOTE
 QUOTE
 QUOTE
 
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""(In reply to comment #36)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYou could try marking your output as HTML according to URL\n\nI'm not sure whether that suppresses section edit links too, but worth a try IMO."", 'QUOTE\nQUOTE\nQUOTE\n\nCan you check whether your headings are matched by the formatHeadings regexp?', ""Ideally we'd move both TOC and section edit links to JS / CSS."", 'That is our plan for Parsoid output, but not going to happen over night.']",NA,0,"QUOTE\nQUOTE\nQUOTE\n\nCan you check whether your headings are matched by the formatHeadings regexp?"
-9369,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
-
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
+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)
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
+""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).
 
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
 
-Can you check whether your headings are matched by the formatHeadings regexp?
+> * list-style (default to decimal; just an escaped pass-through of the CSS
+> list-style of the OL)
 
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",1382742193,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
+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)
 
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
+""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).
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
 
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
+> * list-style (default to decimal; just an escaped pass-through of the CSS
+> list-style of the OL)
 
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.","(In reply to comment #36)
-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).","(In reply to comment #0)
 QUOTE
 QUOTE
 
-You could try marking your output as HTML according to URL
+""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).
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
 
-QUOTE
 QUOTE
 QUOTE
 
-Can you check whether your headings are matched by the formatHeadings regexp?
+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)
 
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""(In reply to comment #36)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYou could try marking your output as HTML according to URL\n\nI'm not sure whether that suppresses section edit links too, but worth a try IMO."", 'QUOTE\nQUOTE\nQUOTE\n\nCan you check whether your headings are matched by the formatHeadings regexp?', ""Ideally we'd move both TOC and section edit links to JS / CSS."", 'That is our plan for Parsoid output, but not going to happen over night.']",NA,0,"That is our plan for Parsoid output, but not going to happen over night."
-9369,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
+""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).
 
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
+> * list-style (default to decimal; just an escaped pass-through of the CSS
+> list-style of the OL)
 
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
+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)
 
-Can you check whether your headings are matched by the formatHeadings regexp?
+""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).
 
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",1382742193,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
 
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
+> * list-style (default to decimal; just an escaped pass-through of the CSS
+> list-style of the OL)
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
-
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
-
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.","(In reply to comment #36)
-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).","(In reply to comment #0)
 QUOTE
 QUOTE
 
-You could try marking your output as HTML according to URL
+""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).
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
 
 QUOTE
 QUOTE
-QUOTE
-
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""(In reply to comment #36)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYou could try marking your output as HTML according to URL\n\nI'm not sure whether that suppresses section edit links too, but worth a try IMO."", 'QUOTE\nQUOTE\nQUOTE\n\nCan you check whether your headings are matched by the formatHeadings regexp?', ""Ideally we'd move both TOC and section edit links to JS / CSS."", 'That is our plan for Parsoid output, but not going to happen over night.']",NA,0,"(In reply to comment #36)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYou could try marking your output as HTML according to URL\n\nI'm not sure whether that suppresses section edit links too, but worth a try IMO."
-9369,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
 
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
+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)
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
+""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).
 
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
 
-Can you check whether your headings are matched by the formatHeadings regexp?
+> * list-style (default to decimal; just an escaped pass-through of the CSS
+> list-style of the OL)
 
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",1382742193,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #36)
-> Issues I have found:
-> 
-> * [MAJOR] Disabling edit section links does not work for headings inside
->  tags
+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)
 
-You could try marking your output as HTML according to https://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modification_of_my_extension.27s_HTML_output.3F
+""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).
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
 
-> * [NORMAL] Edit section links don't work. Not a regression, but would be nice
-> fix. Above issue make this a bigger issue.
-> * [BLOCKER] Table of contents does not include links
+> * list-style (default to decimal; just an escaped pass-through of the CSS
+> list-style of the OL)
 
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.","(In reply to comment #36)
-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).","(In reply to comment #0)
 QUOTE
 QUOTE
 
-You could try marking your output as HTML according to URL
+""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).
 
-I'm not sure whether that suppresses section edit links too, but worth a try IMO.
 
 QUOTE
 QUOTE
-QUOTE
-
-Can you check whether your headings are matched by the formatHeadings regexp?
-
-Ideally we'd move both TOC and section edit links to JS / CSS. That is our plan for Parsoid output, but not going to happen over night.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""(In reply to comment #36)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nYou could try marking your output as HTML according to URL\n\nI'm not sure whether that suppresses section edit links too, but worth a try IMO."", 'QUOTE\nQUOTE\nQUOTE\n\nCan you check whether your headings are matched by the formatHeadings regexp?', ""Ideally we'd move both TOC and section edit links to JS / CSS."", 'That is our plan for Parsoid output, but not going to happen over night.']",NA,0,"Ideally we'd move both TOC and section edit links to JS / CSS."
-9370,"Parsoid should support  and  natively as they are not normal parser tags","Editing translatable pages via API seems to work now.",1382609272,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Editing translatable pages via API seems to work now.","Editing translatable pages via API seems to work now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['Editing translatable pages via API seems to work now.']",NA,0,"Editing translatable pages via API seems to work now."
-9371,"Parsoid should support  and  natively as they are not normal parser tags","Also, please test the patch if you can to see if you find any other changes in behavior.",1382609061,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Also, please test the patch if you can to see if you find any other changes in behavior.","Also, please test the patch if you can to see if you find any other changes in behavior.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['Also, please test the patch if you can to see if you find any other changes in behavior.']",NA,0,"Also, please test the patch if you can to see if you find any other changes in behavior."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"Not a regression, but would be nice fix."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"Above issue make this a bigger issue."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"The original logic cannot be implemented with information provided for the parser hook."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"You can see the buildup at bottom of URL compare with URL ."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"This is annoying and would be nice to fix, but the workaround is to edit page source."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"Documentation about whitespace before has to be update if this way is chosen."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"Please help me solve the remaining issues."
-9372,"Parsoid should support  and  natively as they are not normal parser tags","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",1382608843,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of http://dev.translatewiki.net/wiki/Extension:Translate compare with http://www.mediawiki.org/wiki/Help:Extension:Translate . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.","Issues I have found:
-
-* [MAJOR] Disabling edit section links does not work for headings inside  tags
-* [NORMAL] Edit section links don't work. Not a regression, but would be nice fix. Above issue make this a bigger issue.
-* [BLOCKER] Table of contents does not include links
-* [MINOR] White space trimming behavior has changed. The original logic cannot be implemented with information provided for the parser hook. You can see the buildup at bottom of URL compare with URL . This is annoying and would be nice to fix, but the workaround is to edit page source. Documentation about whitespace before has to be update if this way is chosen.
-
-Please help me solve the remaining issues.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"[""Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."", 'Not a regression, but would be nice fix.', 'Above issue make this a bigger issue.', '* [BLOCKER] Table of contents does not include links\n* [MINOR] White space trimming behavior has changed.', 'The original logic cannot be implemented with information provided for the parser hook.', 'You can see the buildup at bottom of URL compare with URL .', 'This is annoying and would be nice to fix, but the workaround is to edit page source.', 'Documentation about whitespace before has to be update if this way is chosen.', 'Please help me solve the remaining issues.']",NA,0,"Issues I have found:\n\n* [MAJOR] Disabling edit section links does not work for headings inside  tags\n* [NORMAL] Edit section links don't work."
-9373,"Parsoid should support  and  natively as they are not normal parser tags","Change 91583 had a related patch set uploaded by Nikerabbit:
-Add $wgTranslatePageTranslationUseParserHook
-
-https://gerrit.wikimedia.org/r/91583",1382608576,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 91583 had a related patch set uploaded by Nikerabbit:
-Add $wgTranslatePageTranslationUseParserHook
-
-https://gerrit.wikimedia.org/r/91583","Change 91583 had a related patch set uploaded by Nikerabbit:
-Add $wgTranslatePageTranslationUseParserHook
-
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['Change 91583 had a related patch set uploaded by Nikerabbit:\nAdd $wgTranslatePageTranslationUseParserHook\n\nGERRIT_URL']",NA,0,"Change 91583 had a related patch set uploaded by Nikerabbit:\nAdd $wgTranslatePageTranslationUseParserHook\n\nGERRIT_URL"
-9374,"Parsoid should support  and  natively as they are not normal parser tags","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",1382602468,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['Trying the parser hook solution now.', ""I have code like:\n\n\t\t$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {\n\t\t\t$re = '~]+)>(.*?"", "")~u';\n\t\t\t$output = preg_replace( $re, '\\2', $input );\n\n\t\t\t$output = $parser->recursiveTagParse( $output, $frame );\n\t\t\t$output = trim( $output );\n\t\t\treturn $output;\n\t\t} );\n\nThis seems to work okay on simple text, with the exception of section edit links."", ""I'm still trying with more complex pages with templates as well extensions and our tutorial.""]",NA,0,"Trying the parser hook solution now."
-9374,"Parsoid should support  and  natively as they are not normal parser tags","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",1382602468,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['Trying the parser hook solution now.', ""I have code like:\n\n\t\t$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {\n\t\t\t$re = '~]+)>(.*?"", "")~u';\n\t\t\t$output = preg_replace( $re, '\\2', $input );\n\n\t\t\t$output = $parser->recursiveTagParse( $output, $frame );\n\t\t\t$output = trim( $output );\n\t\t\treturn $output;\n\t\t} );\n\nThis seems to work okay on simple text, with the exception of section edit links."", ""I'm still trying with more complex pages with templates as well extensions and our tutorial.""]",NA,0,"I have code like:\n\n\t\t$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {\n\t\t\t$re = '~]+)>(.*?"
-9374,"Parsoid should support  and  natively as they are not normal parser tags","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",1382602468,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['Trying the parser hook solution now.', ""I have code like:\n\n\t\t$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {\n\t\t\t$re = '~]+)>(.*?"", "")~u';\n\t\t\t$output = preg_replace( $re, '\\2', $input );\n\n\t\t\t$output = $parser->recursiveTagParse( $output, $frame );\n\t\t\t$output = trim( $output );\n\t\t\treturn $output;\n\t\t} );\n\nThis seems to work okay on simple text, with the exception of section edit links."", ""I'm still trying with more complex pages with templates as well extensions and our tutorial.""]",NA,0,")~u';\n\t\t\t$output = preg_replace( $re, '\\2', $input );\n\n\t\t\t$output = $parser->recursiveTagParse( $output, $frame );\n\t\t\t$output = trim( $output );\n\t\t\treturn $output;\n\t\t} );\n\nThis seems to work okay on simple text, with the exception of section edit links."
-9374,"Parsoid should support  and  natively as they are not normal parser tags","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",1382602468,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.","Trying the parser hook solution now. I have code like:
-
-		$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {
-			$re = '~]+)>(.*?)~u';
-			$output = preg_replace( $re, '\2', $input );
-
-			$output = $parser->recursiveTagParse( $output, $frame );
-			$output = trim( $output );
-			return $output;
-		} );
-
-This seems to work okay on simple text, with the exception of section edit links.
-
-I'm still trying with more complex pages with templates as well extensions and our tutorial.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,16,NA,"['Trying the parser hook solution now.', ""I have code like:\n\n\t\t$parser->setHook( 'translate', function ( $input, $params, $parser, $frame ) {\n\t\t\t$re = '~]+)>(.*?"", "")~u';\n\t\t\t$output = preg_replace( $re, '\\2', $input );\n\n\t\t\t$output = $parser->recursiveTagParse( $output, $frame );\n\t\t\t$output = trim( $output );\n\t\t\treturn $output;\n\t\t} );\n\nThis seems to work okay on simple text, with the exception of section edit links."", ""I'm still trying with more complex pages with templates as well extensions and our tutorial.""]",NA,0,"I'm still trying with more complex pages with templates as well extensions and our tutorial."
-9375,"Parsoid should support  and  natively as they are not normal parser tags","**gmaruzz** wrote:
-
-bump",1382525422,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","**gmaruzz** wrote:
-
-bump","**gmaruzz** wrote:
-
-bump",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,16,NA,"['**gmaruzz** wrote:\n\nbump']",NA,0,"**gmaruzz** wrote:\n\nbump"
-9376,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",1382026260,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.","Niklas: So, here is what I found:
-
-URL works and does not crash.
-
-URL throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: So, here is what I found:\n\nURL works and does not crash.', 'URL throws the exception.', 'I am a bit baffled why the comment in the extension content should change what hook is called.', ""I'll let you investigate from here."", 'It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.']",NA,0,"Niklas: So, here is what I found:\n\nURL works and does not crash."
-9376,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",1382026260,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.","Niklas: So, here is what I found:
-
-URL works and does not crash.
-
-URL throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: So, here is what I found:\n\nURL works and does not crash.', 'URL throws the exception.', 'I am a bit baffled why the comment in the extension content should change what hook is called.', ""I'll let you investigate from here."", 'It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.']",NA,0,"URL throws the exception."
-9376,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",1382026260,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.","Niklas: So, here is what I found:
-
-URL works and does not crash.
-
-URL throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: So, here is what I found:\n\nURL works and does not crash.', 'URL throws the exception.', 'I am a bit baffled why the comment in the extension content should change what hook is called.', ""I'll let you investigate from here."", 'It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.']",NA,0,"I am a bit baffled why the comment in the extension content should change what hook is called."
-9376,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",1382026260,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.","Niklas: So, here is what I found:
-
-URL works and does not crash.
-
-URL throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: So, here is what I found:\n\nURL works and does not crash.', 'URL throws the exception.', 'I am a bit baffled why the comment in the extension content should change what hook is called.', ""I'll let you investigate from here."", 'It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.']",NA,0,"It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you."
-9376,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",1382026260,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: So, here is what I found:
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo works and does not crash.
-
-https://meta.wikimedia.org/w/api.php?action=parse&text=foo throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.","Niklas: So, here is what I found:
-
-URL works and does not crash.
-
-URL throws the exception.
-
-I am a bit baffled why the comment in the extension content should change what hook is called. I'll let you investigate from here. It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: So, here is what I found:\n\nURL works and does not crash.', 'URL throws the exception.', 'I am a bit baffled why the comment in the extension content should change what hook is called.', ""I'll let you investigate from here."", 'It might be worth using this opportunity to use a regular extension hook (rather than the ParserBeforeStrip hook), if that might work for you.']",NA,0,"I'll let you investigate from here."
-9377,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",1382022809,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: To me, it looks like an existing bug got exposed.', 'Can you provide more details?', 'Maybe full url of the API call?', 'And/or, if you hop onto #mediawiki-parsoid, we could investigate.']",NA,0,"Niklas: To me, it looks like an existing bug got exposed."
-9377,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",1382022809,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: To me, it looks like an existing bug got exposed.', 'Can you provide more details?', 'Maybe full url of the API call?', 'And/or, if you hop onto #mediawiki-parsoid, we could investigate.']",NA,0,"Can you provide more details?"
-9377,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",1382022809,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: To me, it looks like an existing bug got exposed.', 'Can you provide more details?', 'Maybe full url of the API call?', 'And/or, if you hop onto #mediawiki-parsoid, we could investigate.']",NA,0,"Maybe full url of the API call?"
-9377,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",1382022809,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.","Niklas: To me, it looks like an existing bug got exposed. Can you provide more details? Maybe full url of the API call? And/or, if you hop onto #mediawiki-parsoid, we could investigate.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['Niklas: To me, it looks like an existing bug got exposed.', 'Can you provide more details?', 'Maybe full url of the API call?', 'And/or, if you hop onto #mediawiki-parsoid, we could investigate.']",NA,0,"And/or, if you hop onto #mediawiki-parsoid, we could investigate."
-9378,"Parsoid should support  and  natively as they are not normal parser tags","I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown. Does anybody have an idea why?",1381997259,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown. Does anybody have an idea why?","I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown. Does anybody have an idea why?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown.', 'Does anybody have an idea why?']",NA,0,"I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown."
-9378,"Parsoid should support  and  natively as they are not normal parser tags","I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown. Does anybody have an idea why?",1381997259,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown. Does anybody have an idea why?","I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown. Does anybody have an idea why?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,15,NA,"['I just found out that if edit is made via API, the ParserBeforeStrip hook I am using does not get called and the exception is shown.', 'Does anybody have an idea why?']",NA,0,"Does anybody have an idea why?"
-9379,"Parsoid should support  and  natively as they are not normal parser tags","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",1381334518,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag.', 'This is quite expensive as you can imagine.', '* This lets the translate hack work for now.', ""At least it won't crash."", '* The translate extension will crash once we actually call the registered tag hook.', 'So there is some time to fix this up, but we should not pretend that it is fixed right now.', 'Can you provide more information on what stops you from using the actual tag hook?']",NA,0,"To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag."
-9379,"Parsoid should support  and  natively as they are not normal parser tags","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",1381334518,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag.', 'This is quite expensive as you can imagine.', '* This lets the translate hack work for now.', ""At least it won't crash."", '* The translate extension will crash once we actually call the registered tag hook.', 'So there is some time to fix this up, but we should not pretend that it is fixed right now.', 'Can you provide more information on what stops you from using the actual tag hook?']",NA,0,"This is quite expensive as you can imagine."
-9379,"Parsoid should support  and  natively as they are not normal parser tags","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",1381334518,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag.', 'This is quite expensive as you can imagine.', '* This lets the translate hack work for now.', ""At least it won't crash."", '* The translate extension will crash once we actually call the registered tag hook.', 'So there is some time to fix this up, but we should not pretend that it is fixed right now.', 'Can you provide more information on what stops you from using the actual tag hook?']",NA,0,"* This lets the translate hack work for now."
-9379,"Parsoid should support  and  natively as they are not normal parser tags","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",1381334518,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag.', 'This is quite expensive as you can imagine.', '* This lets the translate hack work for now.', ""At least it won't crash."", '* The translate extension will crash once we actually call the registered tag hook.', 'So there is some time to fix this up, but we should not pretend that it is fixed right now.', 'Can you provide more information on what stops you from using the actual tag hook?']",NA,0,"* The translate extension will crash once we actually call the registered tag hook."
-9379,"Parsoid should support  and  natively as they are not normal parser tags","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",1381334518,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag.', 'This is quite expensive as you can imagine.', '* This lets the translate hack work for now.', ""At least it won't crash."", '* The translate extension will crash once we actually call the registered tag hook.', 'So there is some time to fix this up, but we should not pretend that it is fixed right now.', 'Can you provide more information on what stops you from using the actual tag hook?']",NA,0,"So there is some time to fix this up, but we should not pretend that it is fixed right now."
-9379,"Parsoid should support  and  natively as they are not normal parser tags","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",1381334518,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag.', 'This is quite expensive as you can imagine.', '* This lets the translate hack work for now.', ""At least it won't crash."", '* The translate extension will crash once we actually call the registered tag hook.', 'So there is some time to fix this up, but we should not pretend that it is fixed right now.', 'Can you provide more information on what stops you from using the actual tag hook?']",NA,0,"Can you provide more information on what stops you from using the actual tag hook?"
-9379,"Parsoid should support  and  natively as they are not normal parser tags","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",1381334518,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?","To summarize:
-
-* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag. This is quite expensive as you can imagine.
-* This lets the translate hack work for now. At least it won't crash.
-* The translate extension will crash once we actually call the registered tag hook.
-
-So there is some time to fix this up, but we should not pretend that it is fixed right now.
-
-Can you provide more information on what stops you from using the actual tag hook?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['To summarize:\n\n* We currently work around the missing tag hook API by calling the full action=parse pipeline for each extension tag.', 'This is quite expensive as you can imagine.', '* This lets the translate hack work for now.', ""At least it won't crash."", '* The translate extension will crash once we actually call the registered tag hook.', 'So there is some time to fix this up, but we should not pretend that it is fixed right now.', 'Can you provide more information on what stops you from using the actual tag hook?']",NA,0,"At least it won't crash."
-9380,"Parsoid should support  and  natively as they are not normal parser tags","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).",1381334222,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Okay, we tested and all is good for now.', 'You can ignore #c27 :-).', 'As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).']",NA,0,"Okay, we tested and all is good for now."
-9380,"Parsoid should support  and  natively as they are not normal parser tags","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).",1381334222,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Okay, we tested and all is good for now.', 'You can ignore #c27 :-).', 'As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).']",NA,0,"You can ignore #c27 :-)."
-9380,"Parsoid should support  and  natively as they are not normal parser tags","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).",1381334222,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).","Okay, we tested and all is good for now. You can ignore #c27 :-). 
-
-As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Okay, we tested and all is good for now.', 'You can ignore #c27 :-).', 'As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly).']",NA,0,"As I indicated in #c26, this is a problem for when we start updating Parsoid code to call extensions directly rather than go through the full parse pipeline (which was meant to be a temporary hack while we figured out how to call extensions directly)."
-9381,"Parsoid should support  and  natively as they are not normal parser tags","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",1381332394,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Actually, now that I wrote that, I might have misspoken about whether it will work now as well.', 'Niklas is right.', 'For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work.', 'Parsoid will recognize the hooks because of the registration.', 'In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.', 'One of us (Gabriel or me) will experiment with the updated code locally and update this bug.']",NA,0,"Actually, now that I wrote that, I might have misspoken about whether it will work now as well."
-9381,"Parsoid should support  and  natively as they are not normal parser tags","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",1381332394,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Actually, now that I wrote that, I might have misspoken about whether it will work now as well.', 'Niklas is right.', 'For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work.', 'Parsoid will recognize the hooks because of the registration.', 'In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.', 'One of us (Gabriel or me) will experiment with the updated code locally and update this bug.']",NA,0,"Niklas is right."
-9381,"Parsoid should support  and  natively as they are not normal parser tags","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",1381332394,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Actually, now that I wrote that, I might have misspoken about whether it will work now as well.', 'Niklas is right.', 'For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work.', 'Parsoid will recognize the hooks because of the registration.', 'In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.', 'One of us (Gabriel or me) will experiment with the updated code locally and update this bug.']",NA,0,"For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work."
-9381,"Parsoid should support  and  natively as they are not normal parser tags","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",1381332394,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Actually, now that I wrote that, I might have misspoken about whether it will work now as well.', 'Niklas is right.', 'For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work.', 'Parsoid will recognize the hooks because of the registration.', 'In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.', 'One of us (Gabriel or me) will experiment with the updated code locally and update this bug.']",NA,0,"Parsoid will recognize the hooks because of the registration."
-9381,"Parsoid should support  and  natively as they are not normal parser tags","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",1381332394,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Actually, now that I wrote that, I might have misspoken about whether it will work now as well.', 'Niklas is right.', 'For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work.', 'Parsoid will recognize the hooks because of the registration.', 'In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.', 'One of us (Gabriel or me) will experiment with the updated code locally and update this bug.']",NA,0,"In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb."
-9381,"Parsoid should support  and  natively as they are not normal parser tags","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",1381332394,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.","Actually, now that I wrote that, I might have misspoken about whether it will work now as well. Niklas is right. For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work. 
-
-Parsoid will recognize the hooks because of the registration. In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.
-
-One of us (Gabriel or me) will experiment with the updated code locally and update this bug.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Actually, now that I wrote that, I might have misspoken about whether it will work now as well.', 'Niklas is right.', 'For  and  tags found in top-level pages, since we never go through PHP parser at all, this may still not work.', 'Parsoid will recognize the hooks because of the registration.', 'In turn, it will call the PHP parser to translate the extension content, which in turn may callback into the translate extension rather than the ParserBeforeStrip callback (which is what  and  relies on), and that will bomb.', 'One of us (Gabriel or me) will experiment with the updated code locally and update this bug.']",NA,0,"One of us (Gabriel or me) will experiment with the updated code locally and update this bug."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook)."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"Anything this is something we could discuss more."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"Hope this summarizes where we stand now."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."
-9382,"Parsoid should support  and  natively as they are not normal parser tags","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",1381331649,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.","The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks. But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.
-
-Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook). So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.
-
-If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work. However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point.
-
-So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser. 
-
-I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms. We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline. Anything this is something we could discuss more.
-
-Hope this summarizes where we stand now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['The patch will work with Parsoid right now, because Parsoid always goes through the PHP parser when dealing with extensions and tag hooks.', 'But, there are plans for Parsoid to bypass the PHP parser and call the extensions/hooks directly.', 'Right now, The translate code preprocesses the page by stripping the  and  tags before the PHP parser actually parses the page source (by registering for ParserBeforeStrip hook).', 'So, even though the tag hooks are registered (with a callback that bombs if called), the PHP parser never gets to calling them.', 'If Parsoid is able to mimic the behavior (by calling all hooks, not just extension callback hooks), the existing code will continue to work.', ""However, if Parsoid only supports tag extensions directly, then, the ParserBeforeStrip code won't be invoked by Parsoid at that time and this will be a problem at that point."", 'So, this is not an issue *right now*, but could be at a later point depending on what functionality Parsoid will implement natively and what it will continue to defer to the PHP parser.', ""I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."", 'We could streamline extensions to go through narrow interfaces rather than continuing to use all sort of hooks into various points of the parsing timeline.', 'Anything this is something we could discuss more.', 'Hope this summarizes where we stand now.']",NA,0,"I think Gabriel was responding to that future concern and also hoping that we can use the opportunity of Parsoid's ongoing development to cleanup some of these interfaces and mechanisms."
-9383,"Parsoid should support  and  natively as they are not normal parser tags","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.",1381311581,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Misunderstanding or miscommunication about the actual requirements is not scope creep.', 'The patch which was made does not add value.', 'I changed the title to reflect the issue with my understanding of it.']",NA,0,"Misunderstanding or miscommunication about the actual requirements is not scope creep."
-9383,"Parsoid should support  and  natively as they are not normal parser tags","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.",1381311581,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Misunderstanding or miscommunication about the actual requirements is not scope creep.', 'The patch which was made does not add value.', 'I changed the title to reflect the issue with my understanding of it.']",NA,0,"The patch which was made does not add value."
-9383,"Parsoid should support  and  natively as they are not normal parser tags","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.",1381311581,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.","Misunderstanding or miscommunication about the actual requirements is not scope creep. The patch which was made does not add value. I changed the title to reflect the issue with my understanding of it.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"['Misunderstanding or miscommunication about the actual requirements is not scope creep.', 'The patch which was made does not add value.', 'I changed the title to reflect the issue with my understanding of it.']",NA,0,"I changed the title to reflect the issue with my understanding of it."
-9384,"Parsoid should support  and  natively as they are not normal parser tags","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See https://translatewiki.net/wiki/Special:Version?uselang=en: Section ""Parser extension tags"" now shows "" and """,1381308196,"PHID-USER-w5a723w3wes6jd5wskgg","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See https://translatewiki.net/wiki/Special:Version?uselang=en: Section ""Parser extension tags"" now shows "" and ""","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See URL Section ""Parser extension tags"" now shows "" and """,NA,NA,NA,NA,NA,"True","c1",3,"False",NA,14,NA,"['This issue appears to suffer from scope creep.', 'The requirements of the current summary have been met.', 'See URL Section ""Parser extension tags"" now shows "" and ""']",NA,0,"This issue appears to suffer from scope creep."
-9384,"Parsoid should support  and  natively as they are not normal parser tags","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See https://translatewiki.net/wiki/Special:Version?uselang=en: Section ""Parser extension tags"" now shows "" and """,1381308196,"PHID-USER-w5a723w3wes6jd5wskgg","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See https://translatewiki.net/wiki/Special:Version?uselang=en: Section ""Parser extension tags"" now shows "" and ""","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See URL Section ""Parser extension tags"" now shows "" and """,NA,NA,NA,NA,NA,"True","c1",3,"False",NA,14,NA,"['This issue appears to suffer from scope creep.', 'The requirements of the current summary have been met.', 'See URL Section ""Parser extension tags"" now shows "" and ""']",NA,0,"The requirements of the current summary have been met."
-9384,"Parsoid should support  and  natively as they are not normal parser tags","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See https://translatewiki.net/wiki/Special:Version?uselang=en: Section ""Parser extension tags"" now shows "" and """,1381308196,"PHID-USER-w5a723w3wes6jd5wskgg","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See https://translatewiki.net/wiki/Special:Version?uselang=en: Section ""Parser extension tags"" now shows "" and ""","This issue appears to suffer from scope creep. The requirements of the current summary have been met. See URL Section ""Parser extension tags"" now shows "" and """,NA,NA,NA,NA,NA,"True","c1",3,"False",NA,14,NA,"['This issue appears to suffer from scope creep.', 'The requirements of the current summary have been met.', 'See URL Section ""Parser extension tags"" now shows "" and ""']",NA,0,"See URL Section ""Parser extension tags"" now shows "" and """
-9385,"Parsoid should support  and  natively as they are not normal parser tags","That patch won't work well with Parsoid, see the comment in the patch set.",1381173268,"PHID-USER-hbtlbu4zftxnz4i6f7yf","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","That patch won't work well with Parsoid, see the comment in the patch set.","That patch won't work well with Parsoid, see the comment in the patch set.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"[""That patch won't work well with Parsoid, see the comment in the patch set.""]",NA,0,"That patch won't work well with Parsoid, see the comment in the patch set."
-9386,"Parsoid should support  and  natively as they are not normal parser tags","I don't deserve the credit for Niklas's fix. :-)",1381161087,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I don't deserve the credit for Niklas's fix. :-)","I don't deserve the credit for Niklas's fix. :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"[""I don't deserve the credit for Niklas's fix."", ':-)']",NA,0,":-)"
-9386,"Parsoid should support  and  natively as they are not normal parser tags","I don't deserve the credit for Niklas's fix. :-)",1381161087,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I don't deserve the credit for Niklas's fix. :-)","I don't deserve the credit for Niklas's fix. :-)",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,14,NA,"[""I don't deserve the credit for Niklas's fix."", ':-)']",NA,0,"I don't deserve the credit for Niklas's fix."
-9387,"Parsoid should support  and  natively as they are not normal parser tags","Change 83427 merged by jenkins-bot:
-Register translate and tvar to the parser
-
-https://gerrit.wikimedia.org/r/83427",1380976648,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 83427 merged by jenkins-bot:
-Register translate and tvar to the parser
-
-https://gerrit.wikimedia.org/r/83427","Change 83427 merged by jenkins-bot:
-Register translate and tvar to the parser
-
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Change 83427 merged by jenkins-bot:\nRegister translate and tvar to the parser\n\nGERRIT_URL']",NA,0,"Change 83427 merged by jenkins-bot:\nRegister translate and tvar to the parser\n\nGERRIT_URL"
-9388,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #19)
-> I think I already did it yesterday.
-
-There is a comment, but now a followup question requires addresssing",1380973744,"PHID-USER-v7bwpq3rs3zdxegibdbh","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #19)
-> I think I already did it yesterday.
-
-There is a comment, but now a followup question requires addresssing","(In reply to comment #19)
-QUOTE
-
-There is a comment, but now a followup question requires addresssing",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #19)\nQUOTE\n\nThere is a comment, but now a followup question requires addresssing']",NA,0,"(In reply to comment #19)\nQUOTE\n\nThere is a comment, but now a followup question requires addresssing"
-9389,"Parsoid should support  and  natively as they are not normal parser tags","I think I already did it yesterday.",1380972312,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I think I already did it yesterday.","I think I already did it yesterday.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I think I already did it yesterday.']",NA,0,"I think I already did it yesterday."
-9390,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #17)
-> Assigning to James, hoping this may get a parsoid person to review the patch
-> that's been available for nearly a month now.
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.",1380903233,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #17)
-> Assigning to James, hoping this may get a parsoid person to review the patch
-> that's been available for nearly a month now.
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.","(In reply to comment #17)
-QUOTE
-QUOTE
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #17)\nQUOTE\nQUOTE\n\nOh.', ""We've been patiently waiting for you to merge it."", ':-(\n\nWill ping the team.']",NA,0,"(In reply to comment #17)\nQUOTE\nQUOTE\n\nOh."
-9390,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #17)
-> Assigning to James, hoping this may get a parsoid person to review the patch
-> that's been available for nearly a month now.
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.",1380903233,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #17)
-> Assigning to James, hoping this may get a parsoid person to review the patch
-> that's been available for nearly a month now.
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.","(In reply to comment #17)
-QUOTE
-QUOTE
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #17)\nQUOTE\nQUOTE\n\nOh.', ""We've been patiently waiting for you to merge it."", ':-(\n\nWill ping the team.']",NA,0,":-(\n\nWill ping the team."
-9390,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #17)
-> Assigning to James, hoping this may get a parsoid person to review the patch
-> that's been available for nearly a month now.
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.",1380903233,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #17)
-> Assigning to James, hoping this may get a parsoid person to review the patch
-> that's been available for nearly a month now.
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.","(In reply to comment #17)
-QUOTE
-QUOTE
-
-Oh. We've been patiently waiting for you to merge it. :-(
-
-Will ping the team.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['(In reply to comment #17)\nQUOTE\nQUOTE\n\nOh.', ""We've been patiently waiting for you to merge it."", ':-(\n\nWill ping the team.']",NA,0,"We've been patiently waiting for you to merge it."
-9391,"Parsoid should support  and  natively as they are not normal parser tags","Assigning to James, hoping this may get a parsoid person to review the patch that's been available for nearly a month now.",1380870838,"PHID-USER-w5a723w3wes6jd5wskgg","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Assigning to James, hoping this may get a parsoid person to review the patch that's been available for nearly a month now.","Assigning to James, hoping this may get a parsoid person to review the patch that's been available for nearly a month now.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"[""Assigning to James, hoping this may get a parsoid person to review the patch that's been available for nearly a month now.""]",NA,0,"Assigning to James, hoping this may get a parsoid person to review the patch that's been available for nearly a month now."
-9392,"Parsoid should support  and  natively as they are not normal parser tags","fwiw this bug has been mentioned at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VisualEditor_weekly_update_-_2013-09-26_.28MW_1.22wmf19.29
-
-I have also seen this problem here and there while editing at mediawiki.org. Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.",1380324098,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","fwiw this bug has been mentioned at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VisualEditor_weekly_update_-_2013-09-26_.28MW_1.22wmf19.29
-
-I have also seen this problem here and there while editing at mediawiki.org. Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.","fwiw this bug has been mentioned at URL
-
-I have also seen this problem here and there while editing at mediawiki.org. Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['fwiw this bug has been mentioned at URL\n\nI have also seen this problem here and there while editing at mediawiki.org.', 'Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.']",NA,0,"fwiw this bug has been mentioned at URL\n\nI have also seen this problem here and there while editing at mediawiki.org."
-9392,"Parsoid should support  and  natively as they are not normal parser tags","fwiw this bug has been mentioned at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VisualEditor_weekly_update_-_2013-09-26_.28MW_1.22wmf19.29
-
-I have also seen this problem here and there while editing at mediawiki.org. Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.",1380324098,"PHID-USER-lluzkul4z7us4sxkayss","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","fwiw this bug has been mentioned at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#VisualEditor_weekly_update_-_2013-09-26_.28MW_1.22wmf19.29
-
-I have also seen this problem here and there while editing at mediawiki.org. Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.","fwiw this bug has been mentioned at URL
-
-I have also seen this problem here and there while editing at mediawiki.org. Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,12,NA,"['fwiw this bug has been mentioned at URL\n\nI have also seen this problem here and there while editing at mediawiki.org.', 'Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough.']",NA,0,"Then again these tags are not used in most Wikimedia projects or MediaWikis there so fair enough."
-9393,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #14)
-> In the long term yes, but wont this render VE useless on translatable pages
-> in the short them?
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.",1378773198,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #14)
-> In the long term yes, but wont this render VE useless on translatable pages
-> in the short them?
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.","(In reply to comment #14)
-QUOTE
-QUOTE
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['(In reply to comment #14)\nQUOTE\nQUOTE\n\nYes.', ""On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE."", ""However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.""]",NA,0,"(In reply to comment #14)\nQUOTE\nQUOTE\n\nYes."
-9393,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #14)
-> In the long term yes, but wont this render VE useless on translatable pages
-> in the short them?
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.",1378773198,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #14)
-> In the long term yes, but wont this render VE useless on translatable pages
-> in the short them?
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.","(In reply to comment #14)
-QUOTE
-QUOTE
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['(In reply to comment #14)\nQUOTE\nQUOTE\n\nYes.', ""On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE."", ""However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.""]",NA,0,"On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE."
-9393,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #14)
-> In the long term yes, but wont this render VE useless on translatable pages
-> in the short them?
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.",1378773198,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #14)
-> In the long term yes, but wont this render VE useless on translatable pages
-> in the short them?
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.","(In reply to comment #14)
-QUOTE
-QUOTE
-
-Yes. On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE.
-
-However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['(In reply to comment #14)\nQUOTE\nQUOTE\n\nYes.', ""On MW.org you can use the alien node editor to edit any extension node's contents (but they won't be rich), but on other wikis it will make them un-editable in VE."", ""However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs.""]",NA,0,"However, making a Translation extension editor in VE shouldn't be hard at all - I've created that as bug 53974 along the lines of other bugs."
-9394,"Parsoid should support  and  natively as they are not normal parser tags","In the long term yes, but wont this render VE useless on translatable pages in the short them?",1378772376,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","In the long term yes, but wont this render VE useless on translatable pages in the short them?","In the long term yes, but wont this render VE useless on translatable pages in the short them?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['In the long term yes, but wont this render VE useless on translatable pages in the short them?']",NA,0,"In the long term yes, but wont this render VE useless on translatable pages in the short them?"
-9395,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",1378754413,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['Niklas: If VE has to support editing for , , etc.', 'tags, Parsoid has to know about those tags.', 'Parsoid finds out about installed tags by querying mediawiki API.', 'So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.']",NA,0,"Niklas: If VE has to support editing for , , etc."
-9395,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",1378754413,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['Niklas: If VE has to support editing for , , etc.', 'tags, Parsoid has to know about those tags.', 'Parsoid finds out about installed tags by querying mediawiki API.', 'So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.']",NA,0,"tags, Parsoid has to know about those tags."
-9395,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",1378754413,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['Niklas: If VE has to support editing for , , etc.', 'tags, Parsoid has to know about those tags.', 'Parsoid finds out about installed tags by querying mediawiki API.', 'So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.']",NA,0,"Parsoid finds out about installed tags by querying mediawiki API."
-9395,"Parsoid should support  and  natively as they are not normal parser tags","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",1378754413,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.","Niklas: If VE has to support editing for , , etc. tags, Parsoid has to know about those tags. Parsoid finds out about installed tags by querying mediawiki API. So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['Niklas: If VE has to support editing for , , etc.', 'tags, Parsoid has to know about those tags.', 'Parsoid finds out about installed tags by querying mediawiki API.', 'So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them.']",NA,0,"So, either MW API should expose this information for hooks automatically or we need a different API endpoint, or you have to register them."
-9396,"Parsoid should support  and  natively as they are not normal parser tags","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.",1378751046,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['See the above commit.', 'It is not thoroughly tested.', ""I still don't understand what would the benefit.""]",NA,0,"See the above commit."
-9396,"Parsoid should support  and  natively as they are not normal parser tags","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.",1378751046,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['See the above commit.', 'It is not thoroughly tested.', ""I still don't understand what would the benefit.""]",NA,0,"It is not thoroughly tested."
-9396,"Parsoid should support  and  natively as they are not normal parser tags","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.",1378751046,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.","See the above commit. It is not thoroughly tested. I still don't understand what would the benefit.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,10,NA,"['See the above commit.', 'It is not thoroughly tested.', ""I still don't understand what would the benefit.""]",NA,0,"I still don't understand what would the benefit."
-9397,"Parsoid should support  and  natively as they are not normal parser tags","Change 83427 had a related patch set uploaded by Nikerabbit:
-Register translate and tvar to the parser
-
-https://gerrit.wikimedia.org/r/83427",1378750854,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Change 83427 had a related patch set uploaded by Nikerabbit:
-Register translate and tvar to the parser
-
-https://gerrit.wikimedia.org/r/83427","Change 83427 had a related patch set uploaded by Nikerabbit:
-Register translate and tvar to the parser
-
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"['Change 83427 had a related patch set uploaded by Nikerabbit:\nRegister translate and tvar to the parser\n\nGERRIT_URL']",NA,0,"Change 83427 had a related patch set uploaded by Nikerabbit:\nRegister translate and tvar to the parser\n\nGERRIT_URL"
-9398,"Parsoid should support  and  natively as they are not normal parser tags","Ping.",1377214396,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Ping.","Ping.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,7,NA,"['Ping.']",NA,0,"Ping."
-9399,"Parsoid should support  and  natively as they are not normal parser tags","Does someone want to try registering them and see what happens? I probably don't have time before Wikimania.",1375385299,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Does someone want to try registering them and see what happens? I probably don't have time before Wikimania.","Does someone want to try registering them and see what happens? I probably don't have time before Wikimania.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['Does someone want to try registering them and see what happens?', ""I probably don't have time before Wikimania.""]",NA,0,"Does someone want to try registering them and see what happens?"
-9399,"Parsoid should support  and  natively as they are not normal parser tags","Does someone want to try registering them and see what happens? I probably don't have time before Wikimania.",1375385299,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Does someone want to try registering them and see what happens? I probably don't have time before Wikimania.","Does someone want to try registering them and see what happens? I probably don't have time before Wikimania.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['Does someone want to try registering them and see what happens?', ""I probably don't have time before Wikimania.""]",NA,0,"I probably don't have time before Wikimania."
-9400,"Parsoid should support  and  natively as they are not normal parser tags","I don't know. Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.",1375380363,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I don't know. Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.","I don't know. Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"[""I don't know."", 'Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.']",NA,0,"Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality."
-9400,"Parsoid should support  and  natively as they are not normal parser tags","I don't know. Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.",1375380363,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","I don't know. Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.","I don't know. Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"[""I don't know."", 'Either the registration would just be symbolic without any side effects, or it could also interfere with the current functionality.']",NA,0,"I don't know."
-9401,"Parsoid should support  and  natively as they are not normal parser tags","@Niklas are there issues with registering them?",1375380132,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","@Niklas are there issues with registering them?","SCREEN_NAME are there issues with registering them?",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['SCREEN_NAME are there issues with registering them?']",NA,0,"SCREEN_NAME are there issues with registering them?"
-9402,"Parsoid should support  and  natively as they are not normal parser tags","*** Bug 52408 has been marked as a duplicate of this bug. ***",1375378489,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","*** Bug 52408 has been marked as a duplicate of this bug. ***","*** Bug 52408 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['*** Bug 52408 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 52408 has been marked as a duplicate of this bug."
-9402,"Parsoid should support  and  natively as they are not normal parser tags","*** Bug 52408 has been marked as a duplicate of this bug. ***",1375378489,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","*** Bug 52408 has been marked as a duplicate of this bug. ***","*** Bug 52408 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['*** Bug 52408 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-9403,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",1375378361,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.', 'This will also let VE support them in the future and protect them from being modified right now.', 'Is there any other way to discover that , ,  are valid tags on the wiki, i.e.', 'what is the mediawiki api endpoint?', ""So far we've been using siprop and fetching installed extension tags and use that to detect these.""]",NA,0,"Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text."
-9403,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",1375378361,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.', 'This will also let VE support them in the future and protect them from being modified right now.', 'Is there any other way to discover that , ,  are valid tags on the wiki, i.e.', 'what is the mediawiki api endpoint?', ""So far we've been using siprop and fetching installed extension tags and use that to detect these.""]",NA,0,"This will also let VE support them in the future and protect them from being modified right now."
-9403,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",1375378361,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.', 'This will also let VE support them in the future and protect them from being modified right now.', 'Is there any other way to discover that , ,  are valid tags on the wiki, i.e.', 'what is the mediawiki api endpoint?', ""So far we've been using siprop and fetching installed extension tags and use that to detect these.""]",NA,0,"Is there any other way to discover that , ,  are valid tags on the wiki, i.e."
-9403,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",1375378361,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.', 'This will also let VE support them in the future and protect them from being modified right now.', 'Is there any other way to discover that , ,  are valid tags on the wiki, i.e.', 'what is the mediawiki api endpoint?', ""So far we've been using siprop and fetching installed extension tags and use that to detect these.""]",NA,0,"what is the mediawiki api endpoint?"
-9403,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",1375378361,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.","Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.  This will also let VE support them in the future and protect them from being modified right now.
-
-Is there any other way to discover that , ,  are valid tags on the wiki, i.e. what is the mediawiki api endpoint?  So far we've been using siprop and fetching installed extension tags and use that to detect these.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,4,NA,"['Parsoid needs to know if something is a valid extension tag so that it can process them rather than escape them to literal text.', 'This will also let VE support them in the future and protect them from being modified right now.', 'Is there any other way to discover that , ,  are valid tags on the wiki, i.e.', 'what is the mediawiki api endpoint?', ""So far we've been using siprop and fetching installed extension tags and use that to detect these.""]",NA,0,"So far we've been using siprop and fetching installed extension tags and use that to detect these."
-9404,"Parsoid should support  and  natively as they are not normal parser tags"," and  are not a normal extension tags. Please explain why I should register them.",1369809699,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment"," and  are not a normal extension tags. Please explain why I should register them."," and  are not a normal extension tags. Please explain why I should register them.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"[' and  are not a normal extension tags.', 'Please explain why I should register them.']",NA,0," and  are not a normal extension tags."
-9404,"Parsoid should support  and  natively as they are not normal parser tags"," and  are not a normal extension tags. Please explain why I should register them.",1369809699,"PHID-USER-732lqsmz4v6bss3kln2v","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment"," and  are not a normal extension tags. Please explain why I should register them."," and  are not a normal extension tags. Please explain why I should register them.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"[' and  are not a normal extension tags.', 'Please explain why I should register them.']",NA,0,"Please explain why I should register them."
-9405,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #2)
-> Parsoid does fetch a list of registered extensions from the config and uses
-> that to wrap the block with mw:Object/Extension/ type. All
-> other unknown tags are pass through as plain text.
-
-Ah, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this. Re-filing.",1369765885,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #2)
-> Parsoid does fetch a list of registered extensions from the config and uses
-> that to wrap the block with mw:Object/Extension/ type. All
-> other unknown tags are pass through as plain text.
-
-Ah, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this. Re-filing.","(In reply to comment #2)
-QUOTE
-QUOTE
-QUOTE
-
-Ah, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this. Re-filing.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nAh, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this."", 'Re-filing.']",NA,0,"Re-filing."
-9405,"Parsoid should support  and  natively as they are not normal parser tags","(In reply to comment #2)
-> Parsoid does fetch a list of registered extensions from the config and uses
-> that to wrap the block with mw:Object/Extension/ type. All
-> other unknown tags are pass through as plain text.
-
-Ah, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this. Re-filing.",1369765885,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","(In reply to comment #2)
-> Parsoid does fetch a list of registered extensions from the config and uses
-> that to wrap the block with mw:Object/Extension/ type. All
-> other unknown tags are pass through as plain text.
-
-Ah, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this. Re-filing.","(In reply to comment #2)
-QUOTE
-QUOTE
-QUOTE
-
-Ah, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this. Re-filing.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"[""(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nAh, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this."", 'Re-filing.']",NA,0,"(In reply to comment #2)\nQUOTE\nQUOTE\nQUOTE\n\nAh, my apologies; I thought you were doing this, but it didn't even occur to me that the Translate extension might fail to do this."
-9406,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?",1369761569,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check URL
-
-Any idea why mw.org is not reporting  as a registered extension?",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"['Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type.', 'All other unknown tags are pass through as plain text.', 'The problem is that mediawiki does not report  as an installed extension.', 'Check URL\n\nAny idea why mw.org is not reporting  as a registered extension?']",NA,0,"Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type."
-9406,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?",1369761569,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check URL
-
-Any idea why mw.org is not reporting  as a registered extension?",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"['Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type.', 'All other unknown tags are pass through as plain text.', 'The problem is that mediawiki does not report  as an installed extension.', 'Check URL\n\nAny idea why mw.org is not reporting  as a registered extension?']",NA,0,"All other unknown tags are pass through as plain text."
-9406,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?",1369761569,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check URL
-
-Any idea why mw.org is not reporting  as a registered extension?",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"['Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type.', 'All other unknown tags are pass through as plain text.', 'The problem is that mediawiki does not report  as an installed extension.', 'Check URL\n\nAny idea why mw.org is not reporting  as a registered extension?']",NA,0,"The problem is that mediawiki does not report  as an installed extension."
-9406,"Parsoid should support  and  natively as they are not normal parser tags","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?",1369761569,"PHID-USER-slccyo5rqasgpljxny7g","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&format=jsonfm&siprop=extensiontags
-
-Any idea why mw.org is not reporting  as a registered extension?","Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type. All other unknown tags are pass through as plain text.
-
-The problem is that mediawiki does not report  as an installed extension.  Check URL
-
-Any idea why mw.org is not reporting  as a registered extension?",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"['Parsoid does fetch a list of registered extensions from the config and uses that to wrap the block with mw:Object/Extension/ type.', 'All other unknown tags are pass through as plain text.', 'The problem is that mediawiki does not report  as an installed extension.', 'Check URL\n\nAny idea why mw.org is not reporting  as a registered extension?']",NA,0,"Check URL\n\nAny idea why mw.org is not reporting  as a registered extension?"
-9407,"Parsoid should support  and  natively as they are not normal parser tags","Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn't recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn't been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?",1369745248,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn't recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn't been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?","Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn't recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn't been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"['Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn\'t recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn\'t been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?']",NA,0,"Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn\"
-9407,"Parsoid should support  and  natively as they are not normal parser tags","Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn't recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn't been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?",1369745248,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-jpmjmzcf4crsjhqwquzp","task_subcomment","Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn't recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn't been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?","Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn't recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn't been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-5,NA,"['Yes, the Translate extension needs to be extended to support VisualEditor editing, but the core issue is that Parsoid doesn\'t recognise  as an extension block; should it take the local list of registered extensions, and for ones it hasn\'t been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?']",NA,0,"t been told how to deal with just wrap it as a typeof=""mw:Object/Unknown"" or something similar?"
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"VisualEditor: Data model needs characters, not code points."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"For instance, U+282E2 (\"
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0," in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2""."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"In a plain textarea, this behaves like a single character from the point of view of the user."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates)."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"2) Combining accents can be used in sequences to build up abstract characters."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent)."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent)."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Then we can refine splitCharacters as needed."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \"
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0," can still detect the simple cases."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"This sounds like a big change for a small issue, but I think it would avoid problems in the future."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"--------------------------\n**Version**: unspecified\n**Severity**: normal"
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."
-9509,"VisualEditor: Data model needs characters, not code points","At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal",1369029300,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_description","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","VisualEditor: Data model needs characters, not code points./n/nAt present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters. Here are two cases where this causes bugs:
-
-1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF. For instance, U+282E2 ('elevator' in Cantonese) is a single character represented in Javascript as ""\uD860\uDEE2"". In a plain textarea, this behaves like a single character from the point of view of the user. However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16. (see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).
-
-2) Combining accents can be used in sequences to build up abstract characters. For example, the Javascript string ""m\u0300"" represents a single abstract character (m with grave accent). In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent). However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.
-
-These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\uD860', '\uDEE2', ..., 'm', '\u0300']). My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\uD860\uDEE2', ..., 'm\u0300'], where each element represents a whole character.
-
-A good start would be to abstract out away calls to string.split( '' ) into a single function like this:
-
-  ve.splitCharacters = function ( value ) {
-      return value.split( /(?![\uDC00-\uDFFF])/ ); // don't split surrogate pairs
-  };
-
-The rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character. Then we can refine splitCharacters as needed.
-
-Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that 'typeof data[i] === ""string""' can still detect the simple cases.
-
-This sounds like a big change for a small issue, but I think it would avoid problems in the future. With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.
-
---------------------------
-**Version**: unspecified
-**Severity**: normal","Medium",50,1370532382,NA,"resolved","True","c1",1,"False","False",-6,NA,"['VisualEditor: Data model needs characters, not code points.', 'At present, the VisualEditor treats UTF-16 code points as if they were synonymous with abstract characters.', 'Here are two cases where this causes bugs:\n\n1) UTF-16 uses a surrogate pair to represent each Unicode character above U+FFFF.', 'For instance, U+282E2 (\'elevator\' in Cantonese) is a single character represented in Javascript as ""\\uD860\\uDEE2"".', 'In a plain textarea, this behaves like a single character from the point of view of the user.', 'However in the VisualEditor, cursoring and backspacing requires two presses; and after cursoring once, any text typed will go in the middle of the surrogate pair, creating invalid UTF-16.', '(see The Unicode Standard, Version 6.2, Section 3.8, Surrogates).', '2) Combining accents can be used in sequences to build up abstract characters.', 'For example, the Javascript string ""m\\u0300"" represents a single abstract character (m with grave accent).', 'In a plain textarea, this behaves like a single character when cursoring, but like two characters when backspacing (so the first backspace just removes the accent).', 'However in the VisualEditor, cursoring requires two presses; and after cursoring once, any typed text will go between the letter and the accent, creating an inappropriate dangling combining accent.', ""These kinds of issues occur because the DataModel uses Arrays with code point elements, say ['\\uD860', '\\uDEE2', ..., 'm', '\\u0300'])."", ""My hunch is that this is slightly too low level, and it should instead use abstract character elements, say ['\\uD860\\uDEE2', ..., 'm\\u0300'], where each element represents a whole character."", ""A good start would be to abstract out away calls to string.split( '' ) into a single function like this:\n\n  ve.splitCharacters = function ( value ) {\n      return value.split( /(?!"", ""[\\uDC00-\\uDFFF])/ ); // don't split surrogate pairs\n  };\n\nThe rest of the codebase should call this function to perform splits, and then not assume that data[i] is a single character."", 'Then we can refine splitCharacters as needed.', 'Alternatively, since the overwhelming majority of characters will in fact be single code points, perhaps the DataModel structure could ""encode"" the exceptional multi-code point characters as objects, so that \'typeof data[i] === ""string""\' can still detect the simple cases.', 'This sounds like a big change for a small issue, but I think it would avoid problems in the future.', 'With a character representation, you can safely perform useful operations like splicing and truncating without having to check the surrounding context very carefully every time.', '--------------------------\n**Version**: unspecified\n**Severity**: normal']",TRUE,0,"string"
-9510,"VisualEditor: Data model needs characters, not code points","Marking this as merged; follow-up in bug 49257.",1370532382,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","Marking this as merged; follow-up in bug 49257.","Marking this as merged; follow-up in bug 49257.",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-4,NA,"['Marking this as merged; follow-up in bug 49257.']",NA,0,"Marking this as merged; follow-up in bug 49257."
-9511,"VisualEditor: Data model needs characters, not code points","*** Bug 49233 has been marked as a duplicate of this bug. ***",1370531722,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","*** Bug 49233 has been marked as a duplicate of this bug. ***","*** Bug 49233 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-4,NA,"['*** Bug 49233 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 49233 has been marked as a duplicate of this bug."
-9511,"VisualEditor: Data model needs characters, not code points","*** Bug 49233 has been marked as a duplicate of this bug. ***",1370531722,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","*** Bug 49233 has been marked as a duplicate of this bug. ***","*** Bug 49233 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",2,"True",NA,-4,NA,"['*** Bug 49233 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-9512,"VisualEditor: Data model needs characters, not code points","Ed's main block of code is merged and will go out with wmf5; keeping this open for follow-up, and removing milestone of tomorrow.",1369497594,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","Ed's main block of code is merged and will go out with wmf5; keeping this open for follow-up, and removing milestone of tomorrow.","Ed's main block of code is merged and will go out with wmf5; keeping this open for follow-up, and removing milestone of tomorrow.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"[""Ed's main block of code is merged and will go out with wmf5; keeping this open for follow-up, and removing milestone of tomorrow.""]",NA,0,"Ed's main block of code is merged and will go out with wmf5; keeping this open for follow-up, and removing milestone of tomorrow."
-9513,"VisualEditor: Data model needs characters, not code points","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",1369309137,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL .', ""We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes."", 'The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct.', 'Then we can get the splitting rules right in isolation.']",NA,0,"To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL ."
-9513,"VisualEditor: Data model needs characters, not code points","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",1369309137,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL .', ""We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes."", 'The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct.', 'Then we can get the splitting rules right in isolation.']",NA,0,"The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct."
-9513,"VisualEditor: Data model needs characters, not code points","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",1369309137,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL .', ""We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes."", 'The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct.', 'Then we can get the splitting rules right in isolation.']",NA,0,"Then we can get the splitting rules right in isolation."
-9513,"VisualEditor: Data model needs characters, not code points","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",1369309137,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (http://unicode.org/reports/tr29/) . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.","To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL . We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes.
-
-The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct. Then we can get the splitting rules right in isolation.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['To be precise about what should constitute a character, see Grapheme Cluster Boundary Rules from TR29 (URL .', ""We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes."", 'The important thing right now is to abstract the code away from assuming single-codepoint characters, so the structure is correct.', 'Then we can get the splitting rules right in isolation.']",NA,0,"We probably want to implement these, except insofar as it differs from the browsers' implementations of what constitutes a character for cursoring purposes."
-9514,"VisualEditor: Data model needs characters, not code points","Related URL: https://gerrit.wikimedia.org/r/64965 (Gerrit Change I8d936fb15d82f73cd45fac142c540a7950850d55)",1369248049,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","Related URL: https://gerrit.wikimedia.org/r/64965 (Gerrit Change I8d936fb15d82f73cd45fac142c540a7950850d55)","Related URL: GERRIT_URL (Gerrit Change I8d936fb15d82f73cd45fac142c540a7950850d55)",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['Related URL: GERRIT_URL (Gerrit Change I8d936fb15d82f73cd45fac142c540a7950850d55)']",NA,0,"Related URL: GERRIT_URL (Gerrit Change I8d936fb15d82f73cd45fac142c540a7950850d55)"
-9515,"VisualEditor: Data model needs characters, not code points","(In reply to comment #3)
-> Another major issue is that window.getSelection (which is what we use to get
-> cursor position, via Rangy) calculates using number of codepoints, not
-> characters, so this would need to be translated.
-
-Which would be done in ve.ce.getOffsetFromTextNode",1369049395,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","(In reply to comment #3)
-> Another major issue is that window.getSelection (which is what we use to get
-> cursor position, via Rangy) calculates using number of codepoints, not
-> characters, so this would need to be translated.
-
-Which would be done in ve.ce.getOffsetFromTextNode","(In reply to comment #3)
-QUOTE
-QUOTE
-QUOTE
-
-Which would be done in ve.ce.getOffsetFromTextNode",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nWhich would be done in ve.ce.getOffsetFromTextNode']",NA,0,"(In reply to comment #3)\nQUOTE\nQUOTE\nQUOTE\n\nWhich would be done in ve.ce.getOffsetFromTextNode"
-9516,"VisualEditor: Data model needs characters, not code points","Another major issue is that window.getSelection (which is what we use to get cursor position, via Rangy) calculates using number of codepoints, not characters, so this would need to be translated.",1369048633,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","Another major issue is that window.getSelection (which is what we use to get cursor position, via Rangy) calculates using number of codepoints, not characters, so this would need to be translated.","Another major issue is that window.getSelection (which is what we use to get cursor position, via Rangy) calculates using number of codepoints, not characters, so this would need to be translated.",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['Another major issue is that window.getSelection (which is what we use to get cursor position, via Rangy) calculates using number of codepoints, not characters, so this would need to be translated.']",NA,0,"Another major issue is that window.getSelection (which is what we use to get cursor position, via Rangy) calculates using number of codepoints, not characters, so this would need to be translated."
-9517,"VisualEditor: Data model needs characters, not code points","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'",1369046846,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['Ideally merging would be done at the transaction level (e.g.', 'in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.', ""Data: ['F','o','o']\n\nTransaction:\n  Retain: 3\n  Replace:\n    Remove: ''\n    Insert: ''\n\nWould become:\n\nTransaction:\n  Retain: 2\n  Replace:\n    Remove: 'o'\n    Insert: 'o'""]",NA,0,"Ideally merging would be done at the transaction level (e.g."
-9517,"VisualEditor: Data model needs characters, not code points","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'",1369046846,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['Ideally merging would be done at the transaction level (e.g.', 'in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.', ""Data: ['F','o','o']\n\nTransaction:\n  Retain: 3\n  Replace:\n    Remove: ''\n    Insert: ''\n\nWould become:\n\nTransaction:\n  Retain: 2\n  Replace:\n    Remove: 'o'\n    Insert: 'o'""]",NA,0,"in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g."
-9517,"VisualEditor: Data model needs characters, not code points","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'",1369046846,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'","Ideally merging would be done at the transaction level (e.g. in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.
-
-Data: ['F','o','o']
-
-Transaction:
-  Retain: 3
-  Replace:
-    Remove: ''
-    Insert: ''
-
-Would become:
-
-Transaction:
-  Retain: 2
-  Replace:
-    Remove: 'o'
-    Insert: 'o'",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-6,NA,"['Ideally merging would be done at the transaction level (e.g.', 'in fixupInsertion), although we would need to extend that method to be allowed to modify the remove part of a transaction, e.g.', ""Data: ['F','o','o']\n\nTransaction:\n  Retain: 3\n  Replace:\n    Remove: ''\n    Insert: ''\n\nWould become:\n\nTransaction:\n  Retain: 2\n  Replace:\n    Remove: 'o'\n    Insert: 'o'""]",NA,0,"Data: ['F','o','o']\n\nTransaction:\n  Retain: 3\n  Replace:\n    Remove: ''\n    Insert: ''\n\nWould become:\n\nTransaction:\n  Retain: 2\n  Replace:\n    Remove: 'o'\n    Insert: 'o'"
-9518,"VisualEditor: Data model needs characters, not code points","A related question is when invalid UTF-16 is checked and how errors are handled. 
-
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",1369029854,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","A related question is when invalid UTF-16 is checked and how errors are handled. 
-
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.","A related question is when invalid UTF-16 is checked and how errors are handled. 
-
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['A related question is when invalid UTF-16 is checked and how errors are handled.', ""I don't know enough to suggest where in the system the checks should be."", 'But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function.', 'Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.']",NA,0,"A related question is when invalid UTF-16 is checked and how errors are handled."
-9518,"VisualEditor: Data model needs characters, not code points","A related question is when invalid UTF-16 is checked and how errors are handled. 
-
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",1369029854,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","A related question is when invalid UTF-16 is checked and how errors are handled. 
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.","A related question is when invalid UTF-16 is checked and how errors are handled. 
+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`
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['A related question is when invalid UTF-16 is checked and how errors are handled.', ""I don't know enough to suggest where in the system the checks should be."", 'But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function.', 'Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.']",NA,0,"But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function."
-9518,"VisualEditor: Data model needs characters, not code points","A related question is when invalid UTF-16 is checked and how errors are handled. 
+**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.
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",1369029854,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","A related question is when invalid UTF-16 is checked and how errors are handled. 
+ 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)
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.","A related question is when invalid UTF-16 is checked and how errors are handled. 
+My OS is Gentoo Linux with everything up-to-date.
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['A related question is when invalid UTF-16 is checked and how errors are handled.', ""I don't know enough to suggest where in the system the checks should be."", 'But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function.', 'Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.']",NA,0,"Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk."
-9518,"VisualEditor: Data model needs characters, not code points","A related question is when invalid UTF-16 is checked and how errors are handled. 
+I fetched the Parsoid extension by using git.
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",1369029854,"PHID-USER-lliyevigiycjbybglftk","PHID-TASK-vqj7c3uh5ndu4ic45odq","task_subcomment","A related question is when invalid UTF-16 is checked and how errors are handled. 
+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.
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.","A related question is when invalid UTF-16 is checked and how errors are handled. 
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-I don't know enough to suggest where in the system the checks should be. But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function. Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-6,NA,"['A related question is when invalid UTF-16 is checked and how errors are handled.', ""I don't know enough to suggest where in the system the checks should be."", 'But it obviously relates to the parts of ve.dm.Converter and ve.ce.Surface (for paste) which would call this new splitCharacters function.', 'Note that two chunks of invalid UTF-16 can concatenate into one valid but unexpected chunk.']",NA,0,"I don't know enough to suggest where in the system the checks should be."
-9929,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Simple test case, see URL:
+And the remaining installation process are with no error.
 
-* foo
-: bar
+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.
 
-adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.
+That is all I have done to the whole Parsoid.
 
 --------------------------
 **Version**: unspecified
 **Severity**: normal
-**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/Finissage
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=60535",1367166420,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-v7tsixpel4mikkpah73h","task_description","VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines./n/nSimple test case, see URL:
+**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`
 
-* foo
-: bar
+**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.
 
-adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.
+ 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
-**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/Finissage
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=60535","VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines./n/nSimple test case, see URL:
+**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
 
-* foo
-: bar
+**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.
 
-adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.
+ 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
-**URL**: URL
-**See Also**:
-URL","Medium",50,1394077374,NA,"resolved","True","c1",1,"False","False",-10,NA,"['VisualEditor: Slugs should be more obvious to the user that they\'re not ""really"" blank lines.', 'Simple test case, see URL:\n\n* foo\n: bar\n\nadds a newline in edit mode.', 'When removing this newline in edit mode the : is killed by the parser.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL\n**See Also**:\nURL']",FALSE,0,"VisualEditor: Slugs should be more obvious to the user that they\"
-9929,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Simple test case, see URL:
+**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`
 
-* foo
-: bar
+**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.
 
-adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.
+ 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
-**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/Finissage
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=60535",1367166420,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-v7tsixpel4mikkpah73h","task_description","VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines./n/nSimple test case, see URL:
+**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`
 
-* foo
-: bar
+**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.
 
-adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.
+ 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
-**URL**: https://de.wikipedia.org/wiki/Benutzer:Raymond/Finissage
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=60535","VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines./n/nSimple test case, see URL:
+**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
 
-* foo
-: bar
+**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.
 
-adds a newline in edit mode. When removing this newline in edit mode the : is killed by the parser.
+ 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
-**URL**: URL
-**See Also**:
-URL","Medium",50,1394077374,NA,"resolved","True","c1",1,"False","False",-10,NA,"['VisualEditor: Slugs should be more obvious to the user that they\'re not ""really"" blank lines.', 'Simple test case, see URL:\n\n* foo\n: bar\n\nadds a newline in edit mode.', 'When removing this newline in edit mode the : is killed by the parser.', '--------------------------\n**Version**: unspecified\n**Severity**: normal\n**URL**: URL\n**See Also**:\nURL']",FALSE,0,"really"
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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`
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+**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.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
-
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
-
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+ 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)
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+My OS is Gentoo Linux with everything up-to-date.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+I fetched the Parsoid extension by using git.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
-
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
-
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"On nl.wp a discussion has started to turn on VE."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+That is all I have done to the whole Parsoid.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+--------------------------
+**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`
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
-
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+ 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)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+My OS is Gentoo Linux with everything up-to-date.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+I fetched the Parsoid extension by using git.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+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.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"In the process feedback has been collected on VE."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+That is all I have done to the whole Parsoid.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+--------------------------
+**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
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+**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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+ 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)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+I fetched the Parsoid extension by using git.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+And the remaining installation process are with no error.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+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.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+That is all I have done to the whole Parsoid.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+--------------------------
+**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`
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"Some users commented on ""white lines"" as a blocking issue for turning VE on as default."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+ 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)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+My OS is Gentoo Linux with everything up-to-date.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+I fetched the Parsoid extension by using git.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+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.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+That is all I have done to the whole Parsoid.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+--------------------------
+**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`
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+**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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+ 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)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+I fetched the Parsoid extension by using git.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+And the remaining installation process are with no error.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+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.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+That is all I have done to the whole Parsoid.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+--------------------------
+**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
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+ 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)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+My OS is Gentoo Linux with everything up-to-date.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+I fetched the Parsoid extension by using git.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"On mouse over the white line turns blue."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+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.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+That is all I have done to the whole Parsoid.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+--------------------------
+**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`
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+**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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+ 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)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+I fetched the Parsoid extension by using git.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"Some users fear that newcomers others will delete those white lines and carriage returns."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+And the remaining installation process are with no error.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+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.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+That is all I have done to the whole Parsoid.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+--------------------------
+**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`
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+ 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)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+My OS is Gentoo Linux with everything up-to-date.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+I fetched the Parsoid extension by using git.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+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.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"However, after deletion of those lines images are accidently deleted from the page."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+That is all I have done to the whole Parsoid.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+--------------------------
+**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
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+**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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+ 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)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+I fetched the Parsoid extension by using git.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+And the remaining installation process are with no error.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+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.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+That is all I have done to the whole Parsoid.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+--------------------------
+**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`
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"This discussion started on bug 49806."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+ 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)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+My OS is Gentoo Linux with everything up-to-date.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+I fetched the Parsoid extension by using git.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+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.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+That is all I have done to the whole Parsoid.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+--------------------------
+**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`
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+**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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+ 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)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"James Forrester pointed me to this bug to continue the discussion."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+I fetched the Parsoid extension by using git.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+And the remaining installation process are with no error.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+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.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+That is all I have done to the whole Parsoid.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+--------------------------
+**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
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+ 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)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+My OS is Gentoo Linux with everything up-to-date.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+I fetched the Parsoid extension by using git.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)"
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+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.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+That is all I have done to the whole Parsoid.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+--------------------------
+**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`
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+**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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+ 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)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+I fetched the Parsoid extension by using git.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+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.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"I will also copy to bug 55336."
-9930,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+And the remaining installation process are with no error.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+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.
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+That is all I have done to the whole Parsoid.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+--------------------------
+**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`
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",1405114275,"PHID-USER-mcyovqjor52nj3se4lq7","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* https://nl.wikipedia.org/wiki/Bali_%28eiland%29?veaction=edit
-* https://nl.wikipedia.org/wiki/Justine_Henin?veaction=edit
-* https://nl.wikipedia.org/wiki/Rijn?veaction=edit
-* https://nl.wikipedia.org/wiki/Brussels_Hoofdstedelijk_Gewest?veaction=edit
-* https://nl.wikipedia.org/wiki/Antwerpen_%28stad%29?veaction=edit
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+**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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+ 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)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+My OS is Gentoo Linux with everything up-to-date.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+I fetched the Parsoid extension by using git.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.","On nl.wp a discussion has started to turn on VE. In the process feedback has been collected on VE. Some users commented on ""white lines"" as a blocking issue for turning VE on as default. 
-On top of pages like:
-* URL
-* URL
-* URL
-* URL
-* URL
-as well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode. On mouse over the white line turns blue. 
+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.
 
-Some users fear that newcomers others will delete those white lines and carriage returns. However, after deletion of those lines images are accidently deleted from the page.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-This discussion started on bug 49806. James Forrester pointed me to this bug to continue the discussion.
+And the remaining installation process are with no error.
 
-(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)
+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.
 
-How can I help to resolve this 'bug'? I will also copy to bug 55336.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,53,NA,"['On nl.wp a discussion has started to turn on VE.', 'In the process feedback has been collected on VE.', 'Some users commented on ""white lines"" as a blocking issue for turning VE on as default.', 'On top of pages like:\n* URL\n* URL\n* URL\n* URL\n* URL\nas well as on other places on the page ""white lines"" or carriage returns appear in VE edit mode which do not appear in read mode.', 'On mouse over the white line turns blue.', 'Some users fear that newcomers others will delete those white lines and carriage returns.', 'However, after deletion of those lines images are accidently deleted from the page.', 'This discussion started on bug 49806.', 'James Forrester pointed me to this bug to continue the discussion.', '(Deleting white space at the bottom of a page might also delete accidently categories and other metadata.)', ""How can I help to resolve this 'bug'?"", 'I will also copy to bug 55336.']",NA,0,"How can I help to resolve this 'bug'?"
-9931,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Initial version of this now merged and being deployed tomorrow. I think we'll want to revisit the styling and behaviour, but this will do for now.",1394077374,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Initial version of this now merged and being deployed tomorrow. I think we'll want to revisit the styling and behaviour, but this will do for now.","Initial version of this now merged and being deployed tomorrow. I think we'll want to revisit the styling and behaviour, but this will do for now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,35,NA,"['Initial version of this now merged and being deployed tomorrow.', ""I think we'll want to revisit the styling and behaviour, but this will do for now.""]",NA,0,"Initial version of this now merged and being deployed tomorrow."
-9931,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Initial version of this now merged and being deployed tomorrow. I think we'll want to revisit the styling and behaviour, but this will do for now.",1394077374,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Initial version of this now merged and being deployed tomorrow. I think we'll want to revisit the styling and behaviour, but this will do for now.","Initial version of this now merged and being deployed tomorrow. I think we'll want to revisit the styling and behaviour, but this will do for now.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,35,NA,"['Initial version of this now merged and being deployed tomorrow.', ""I think we'll want to revisit the styling and behaviour, but this will do for now.""]",NA,0,"I think we'll want to revisit the styling and behaviour, but this will do for now."
-9932,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Change 116742 abandoned by Esanders:
-Vector style tweaks for collapsible slugs
+That is all I have done to the whole Parsoid.
 
-https://gerrit.wikimedia.org/r/116742",1394042895,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Change 116742 abandoned by Esanders:
-Vector style tweaks for collapsible slugs
+--------------------------
+**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
 
-https://gerrit.wikimedia.org/r/116742","Change 116742 abandoned by Esanders:
-Vector style tweaks for collapsible slugs
+**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.
 
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,35,NA,"['Change 116742 abandoned by Esanders:\nVector style tweaks for collapsible slugs\n\nGERRIT_URL']",NA,0,"Change 116742 abandoned by Esanders:\nVector style tweaks for collapsible slugs\n\nGERRIT_URL"
-9933,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Change 109307 merged by jenkins-bot:
-Collapse block slugs and expand on hover/focus
+ 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)
 
-https://gerrit.wikimedia.org/r/109307",1394040062,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Change 109307 merged by jenkins-bot:
-Collapse block slugs and expand on hover/focus
+My OS is Gentoo Linux with everything up-to-date.
 
-https://gerrit.wikimedia.org/r/109307","Change 109307 merged by jenkins-bot:
-Collapse block slugs and expand on hover/focus
+I fetched the Parsoid extension by using git.
 
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,35,NA,"['Change 109307 merged by jenkins-bot:\nCollapse block slugs and expand on hover/focus\n\nGERRIT_URL']",NA,0,"Change 109307 merged by jenkins-bot:\nCollapse block slugs and expand on hover/focus\n\nGERRIT_URL"
-9934,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Change 116742 had a related patch set uploaded by Esanders:
-Vector style tweaks for collapsible slugs
+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.
 
-https://gerrit.wikimedia.org/r/116742",1393942167,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Change 116742 had a related patch set uploaded by Esanders:
-Vector style tweaks for collapsible slugs
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-https://gerrit.wikimedia.org/r/116742","Change 116742 had a related patch set uploaded by Esanders:
-Vector style tweaks for collapsible slugs
+And the remaining installation process are with no error.
 
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,35,NA,"['Change 116742 had a related patch set uploaded by Esanders:\nVector style tweaks for collapsible slugs\n\nGERRIT_URL']",NA,0,"Change 116742 had a related patch set uploaded by Esanders:\nVector style tweaks for collapsible slugs\n\nGERRIT_URL"
-9935,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Change 109307 had a related patch set uploaded by Esanders:
-Collapse block slugs, and expand on hover/focus
+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.
 
-https://gerrit.wikimedia.org/r/109307",1390581550,"PHID-USER-idceizaw6elwiwm5xshb","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Change 109307 had a related patch set uploaded by Esanders:
-Collapse block slugs, and expand on hover/focus
+That is all I have done to the whole Parsoid.
 
-https://gerrit.wikimedia.org/r/109307","Change 109307 had a related patch set uploaded by Esanders:
-Collapse block slugs, and expand on hover/focus
+--------------------------
+**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`
 
-GERRIT_URL",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,29,NA,"['Change 109307 had a related patch set uploaded by Esanders:\nCollapse block slugs, and expand on hover/focus\n\nGERRIT_URL']",NA,0,"Change 109307 had a related patch set uploaded by Esanders:\nCollapse block slugs, and expand on hover/focus\n\nGERRIT_URL"
-9936,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+**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.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+ 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)
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",1381008272,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+I fetched the Parsoid extension by using git.
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+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.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks, Ed, for splitting the issue and working on a patch for bug 55336.', ""Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation."", 'I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.', ""I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative."", 'In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.']",NA,0,"Thanks, Ed, for splitting the issue and working on a patch for bug 55336."
-9936,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+And the remaining installation process are with no error.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+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.
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",1381008272,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+That is all I have done to the whole Parsoid.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+--------------------------
+**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`
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+**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.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+ 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)
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks, Ed, for splitting the issue and working on a patch for bug 55336.', ""Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation."", 'I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.', ""I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative."", 'In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.']",NA,0,"I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall."
-9936,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+I fetched the Parsoid extension by using git.
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",1381008272,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+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.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+And the remaining installation process are with no error.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+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.
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks, Ed, for splitting the issue and working on a patch for bug 55336.', ""Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation."", 'I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.', ""I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative."", 'In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.']",NA,0,"In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page."
-9936,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+That is all I have done to the whole Parsoid.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+--------------------------
+**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
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",1381008272,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+**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.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+ 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)
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+My OS is Gentoo Linux with everything up-to-date.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+I fetched the Parsoid extension by using git.
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks, Ed, for splitting the issue and working on a patch for bug 55336.', ""Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation."", 'I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.', ""I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative."", 'In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.']",NA,0,"Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation."
-9936,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+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.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",1381008272,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+And the remaining installation process are with no error.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+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.
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.","Thanks, Ed, for splitting the issue and working on a patch for bug 55336. 
+That is all I have done to the whole Parsoid.
 
-Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation. I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.
+--------------------------
+**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`
 
-I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative. In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['Thanks, Ed, for splitting the issue and working on a patch for bug 55336.', ""Accordingly, I've set that bug to High/Major and this one to Normal, as the overall UX for slugs is important, but not as significant as the accidental deletion of content with the current implementation."", 'I also suspect that we would want to alter the delete behavior even if we end up altering the slug appearance overall.', ""I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative."", 'In addition to offering an affordance on hover, we might also expand the slugs as the user moves her cursor through the page.']",NA,0,"I do agree that the accidental whitespace is confusing (it's often the most immediate and obvious difference from read mode) and it would be good to find an alternative."
-9937,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**jonathan_haas** wrote:
+**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.
 
-(In reply to comment #15)
-> Why don't we just suppress the delete key when pressing it would delete the
-> object the slug is associated with?
+ 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)
 
-This would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.
+My OS is Gentoo Linux with everything up-to-date.
 
-I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.",1380964477,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**jonathan_haas** wrote:
+I fetched the Parsoid extension by using git.
 
-(In reply to comment #15)
-> Why don't we just suppress the delete key when pressing it would delete the
-> object the slug is associated with?
+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.
 
-This would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.
+net-libs/nodejs Installed versions:  0.10.8^t(19:04:51 07/10/13)
+(masked by default, I unmasked that.)
 
-I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.","**jonathan_haas** wrote:
+And the remaining installation process are with no error.
 
-(In reply to comment #15)
+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
 
-This would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.
+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:
 
-I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['**jonathan_haas** wrote:\n\n(In reply to comment #15)\nQUOTE\nQUOTE\n\nThis would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.', 'I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.']",NA,0,"**jonathan_haas** wrote:\n\n(In reply to comment #15)\nQUOTE\nQUOTE\n\nThis would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout."
-9937,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**jonathan_haas** 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)
 
-(In reply to comment #15)
-> Why don't we just suppress the delete key when pressing it would delete the
-> object the slug is associated with?
+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:
 
-This would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.
+(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)
 
-I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.",1380964477,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**jonathan_haas** wrote:
+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 #15)
-> Why don't we just suppress the delete key when pressing it would delete the
-> object the slug is associated with?
-
-This would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.
-
-I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.","**jonathan_haas** wrote:
-
-(In reply to comment #15)
+(In reply to comment #2)
+QUOTE
 QUOTE
 QUOTE
 
-This would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.
+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:
 
-I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['**jonathan_haas** wrote:\n\n(In reply to comment #15)\nQUOTE\nQUOTE\n\nThis would still leave the user with a superfluous empty line, which might be confusing and/or destroying the page layout.', 'I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one.']",NA,0,"I like the idea in attachment 12988, but I think it would be better, if slugs would have had an effective default height of 0 (for example height: 4px, margin-top: -2px, margin-bottom:-2px), so the article layout would match the real one."
-9938,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336",1380963747,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336","I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes.', 'Here is the latter: bug 55336']",NA,0,"I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes."
-9938,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336",1380963747,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336","I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes. Here is the latter: bug 55336",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,13,NA,"['I think we should split this bug in two: Slugs, and accidental deletion of FocusableNodes.', 'Here is the latter: bug 55336']",NA,0,"Here is the latter: bug 55336"
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
+(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)
 
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
+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:
 
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
+(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)
 
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
+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:
 
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such."
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout."
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears."
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"This is very surprising and counter-intuitive behavior."
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects."
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"That seems like the simplest solution to me and does not require a redesign of the slugs."
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"
-9939,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",1380953506,"PHID-USER-766idcqt4jkngnnuhnrj","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.","I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such. I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions. 
-
-Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout. A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears. This is very surprising and counter-intuitive behavior.
-
-Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with? In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects. I've never had any problems as a result.
-
-That seems like the simplest solution to me and does not require a redesign of the slugs.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,13,NA,"['I agree with previous commenters that this is likely to be at the cause of a lot of the accidental infobox deletions and such.', ""I understand it's a tricky issue, but the current behavior is extremely confusing from the user's point of view, so we need to look at some viable solutions."", 'Recapping the simple case: User is on what they perceive to be an unnecessary newline, presses delete to make the visual layout match the expected layout.', 'A separate object (in the case of the infobox, right-aligned on the other side of the screen) suddenly disappears.', 'This is very surprising and counter-intuitive behavior.', ""Why don't we just suppress the delete key when pressing it would delete the object the slug is associated with?"", 'In some alternative editors like Google Docs, it is actually not possible to nuke the entire document by just pressing down the delete key at the top of the page -- it will stop before certain objects.', ""I've never had any problems as a result."", 'That seems like the simplest solution to me and does not require a redesign of the slugs.']",NA,0,"I've never had any problems as a result."
-9940,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Today JohnCD asked again about this and I got another report from fr.wp, https://fr.wikipedia.org/w/index.php?title=Osmium&diff=96605232&oldid=93301425 .
-Hoping this gets some love soon :)",1379004776,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Today JohnCD asked again about this and I got another report from fr.wp, https://fr.wikipedia.org/w/index.php?title=Osmium&diff=96605232&oldid=93301425 .
-Hoping this gets some love soon :)","Today JohnCD asked again about this and I got another report from fr.wp, URL .
-Hoping this gets some love soon :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"['Today JohnCD asked again about this and I got another report from fr.wp, URL .', 'Hoping this gets some love soon :)']",NA,0,"Today JohnCD asked again about this and I got another report from fr.wp, URL ."
-9940,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Today JohnCD asked again about this and I got another report from fr.wp, https://fr.wikipedia.org/w/index.php?title=Osmium&diff=96605232&oldid=93301425 .
-Hoping this gets some love soon :)",1379004776,"PHID-USER-wil4b5lylrvf3krixlkl","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Today JohnCD asked again about this and I got another report from fr.wp, https://fr.wikipedia.org/w/index.php?title=Osmium&diff=96605232&oldid=93301425 .
-Hoping this gets some love soon :)","Today JohnCD asked again about this and I got another report from fr.wp, URL .
-Hoping this gets some love soon :)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,10,NA,"['Today JohnCD asked again about this and I got another report from fr.wp, URL .', 'Hoping this gets some love soon :)']",NA,0,"Hoping this gets some love soon :)"
-9941,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","*** Bug 52172 has been marked as a duplicate of this bug. ***",1375047891,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","*** Bug 52172 has been marked as a duplicate of this bug. ***","*** Bug 52172 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['*** Bug 52172 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 52172 has been marked as a duplicate of this bug."
-9941,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","*** Bug 52172 has been marked as a duplicate of this bug. ***",1375047891,"PHID-USER-oxd6f6xemkuyttw7z7wl","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","*** Bug 52172 has been marked as a duplicate of this bug. ***","*** Bug 52172 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['*** Bug 52172 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-9942,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Created attachment 12988
-Copy of http://i.imgur.com/39QQi8U.png
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}",1374960319,"PHID-USER-hyfm4swq76s4j642w46x","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Created attachment 12988
-Copy of http://i.imgur.com/39QQi8U.png
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}","Created attachment 12988
-Copy of URL
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Created attachment 12988\nCopy of URL\n\nPlease upload attachments to Bugzilla.', 'imgur periodically prunes images; Bugzilla does not.', ':-)\n\n**Attached**: {F10355}']",NA,0,"Created attachment 12988\nCopy of URL\n\nPlease upload attachments to Bugzilla."
-9942,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Created attachment 12988
-Copy of http://i.imgur.com/39QQi8U.png
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}",1374960319,"PHID-USER-hyfm4swq76s4j642w46x","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Created attachment 12988
-Copy of http://i.imgur.com/39QQi8U.png
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}","Created attachment 12988
-Copy of URL
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Created attachment 12988\nCopy of URL\n\nPlease upload attachments to Bugzilla.', 'imgur periodically prunes images; Bugzilla does not.', ':-)\n\n**Attached**: {F10355}']",NA,0,"imgur periodically prunes images; Bugzilla does not."
-9942,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Created attachment 12988
-Copy of http://i.imgur.com/39QQi8U.png
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}",1374960319,"PHID-USER-hyfm4swq76s4j642w46x","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Created attachment 12988
-Copy of http://i.imgur.com/39QQi8U.png
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}","Created attachment 12988
-Copy of URL
-
-Please upload attachments to Bugzilla. imgur periodically prunes images; Bugzilla does not. :-)
-
-**Attached**: {F10355}",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,3,NA,"['Created attachment 12988\nCopy of URL\n\nPlease upload attachments to Bugzilla.', 'imgur periodically prunes images; Bugzilla does not.', ':-)\n\n**Attached**: {F10355}']",NA,0,":-)\n\n**Attached**: {F10355}"
-9943,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Suggestion:
-http://i.imgur.com/39QQi8U.png",1374926957,"PHID-USER-it53o2f2kyryqyj33uzt","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Suggestion:
-http://i.imgur.com/39QQi8U.png","Suggestion:
-URL",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,3,NA,"['Suggestion:\nURL']",NA,0,"Suggestion:\nURL"
-9944,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",1374396945,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**JohnCD67** wrote:\n\nThis causes trouble in the fairly common operation of removing a template (e.g.', 'a PROD) from the top of a page which has an infobox.', 'Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top.', 'The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box.', '(Win7, FF22.0)']",NA,0,"**JohnCD67** wrote:\n\nThis causes trouble in the fairly common operation of removing a template (e.g."
-9944,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",1374396945,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**JohnCD67** wrote:\n\nThis causes trouble in the fairly common operation of removing a template (e.g.', 'a PROD) from the top of a page which has an infobox.', 'Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top.', 'The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box.', '(Win7, FF22.0)']",NA,0,"a PROD) from the top of a page which has an infobox."
-9944,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",1374396945,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**JohnCD67** wrote:\n\nThis causes trouble in the fairly common operation of removing a template (e.g.', 'a PROD) from the top of a page which has an infobox.', 'Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top.', 'The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box.', '(Win7, FF22.0)']",NA,0,"Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top."
-9944,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",1374396945,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**JohnCD67** wrote:\n\nThis causes trouble in the fairly common operation of removing a template (e.g.', 'a PROD) from the top of a page which has an infobox.', 'Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top.', 'The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box.', '(Win7, FF22.0)']",NA,0,"The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box."
-9944,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",1374396945,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)","**JohnCD67** wrote:
-
-This causes trouble in the fairly common operation of removing a template (e.g. a PROD) from the top of a page which has an infobox. Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top. The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box. (Win7, FF22.0)",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**JohnCD67** wrote:\n\nThis causes trouble in the fairly common operation of removing a template (e.g.', 'a PROD) from the top of a page which has an infobox.', 'Click the template to select it, press ""Delete"" and it goes, leaving apparently a spare blank line at the top.', 'The natural reaction is press ""Delete"" again to remove the blank line, and that takes out the info box.', '(Win7, FF22.0)']",NA,0,"(Win7, FF22.0)"
-9945,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.",1374361883,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**joedecker** wrote:\n\nI suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.', 'As a separate question, can you undo deletion of slugs?', 'If not, I think that would explain another set of problems others and I have observed.']",NA,0,"**joedecker** wrote:\n\nI suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused."
-9945,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.",1374361883,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**joedecker** wrote:\n\nI suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.', 'As a separate question, can you undo deletion of slugs?', 'If not, I think that would explain another set of problems others and I have observed.']",NA,0,"As a separate question, can you undo deletion of slugs?"
-9945,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.",1374361883,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.","**joedecker** wrote:
-
-I suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.  
-
-As a separate question, can you undo deletion of slugs?  If not, I think that would explain another set of problems others and I have observed.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['**joedecker** wrote:\n\nI suspect this is behind a few of the reports (on the ENWIKI feedback page, some of them mine) in which unexpected deletions are caused.', 'As a separate question, can you undo deletion of slugs?', 'If not, I think that would explain another set of problems others and I have observed.']",NA,0,"If not, I think that would explain another set of problems others and I have observed."
-9946,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Gotcha. A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).",1373913566,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Gotcha. A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).","Gotcha. A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Gotcha.', ""A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).""]",NA,0,"Gotcha."
-9946,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Gotcha. A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).",1373913566,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Gotcha. A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).","Gotcha. A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Gotcha.', ""A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :).""]",NA,0,"A user was confused as to why they couldn't add a template to the top of an article without it appearing on the same line :)."
-9947,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","(In reply to comment #4)
-> Does this include the line of whitespace right at the start of articles?
-
-Yes.",1373913377,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","(In reply to comment #4)
-> Does this include the line of whitespace right at the start of articles?
-
-Yes.","(In reply to comment #4)
+(In reply to comment #2)
 QUOTE
-
-Yes.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,2,NA,"['(In reply to comment #4)\nQUOTE\n\nYes.']",NA,0,"(In reply to comment #4)\nQUOTE\n\nYes."
-9948,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","(In reply to comment #5)
-> It looks like this bug was fixed somehow. I cannot longer reproduce it on
-> dewiki.
-
-Yes, we removed the slugs between lists because we felt they were no longer needed given the new editing tools, but they remain more widely.",1373913366,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","(In reply to comment #5)
-> It looks like this bug was fixed somehow. I cannot longer reproduce it on
-> dewiki.
-
-Yes, we removed the slugs between lists because we felt they were no longer needed given the new editing tools, but they remain more widely.","(In reply to comment #5)
 QUOTE
 QUOTE
 
-Yes, we removed the slugs between lists because we felt they were no longer needed given the new editing tools, but they remain more widely.",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,2,NA,"['(In reply to comment #5)\nQUOTE\nQUOTE\n\nYes, we removed the slugs between lists because we felt they were no longer needed given the new editing tools, but they remain more widely.']",NA,0,"(In reply to comment #5)\nQUOTE\nQUOTE\n\nYes, we removed the slugs between lists because we felt they were no longer needed given the new editing tools, but they remain more widely."
-9949,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.",1373909882,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.","It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['It looks like this bug was fixed somehow.', 'I cannot longer reproduce it on dewiki.']",NA,0,"It looks like this bug was fixed somehow."
-9949,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.",1373909882,"PHID-USER-3uecblbxq24ycewm2cog","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.","It looks like this bug was fixed somehow. I cannot longer reproduce it on dewiki.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['It looks like this bug was fixed somehow.', 'I cannot longer reproduce it on dewiki.']",NA,0,"I cannot longer reproduce it on dewiki."
-9950,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","Does this include the line of whitespace right at the start of articles?",1373879923,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","Does this include the line of whitespace right at the start of articles?","Does this include the line of whitespace right at the start of articles?",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,2,NA,"['Does this include the line of whitespace right at the start of articles?']",NA,0,"Does this include the line of whitespace right at the start of articles?"
-9951,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","*** Bug 50295 has been marked as a duplicate of this bug. ***",1373854867,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","*** Bug 50295 has been marked as a duplicate of this bug. ***","*** Bug 50295 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,2,NA,"['*** Bug 50295 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50295 has been marked as a duplicate of this bug."
-9951,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","*** Bug 50295 has been marked as a duplicate of this bug. ***",1373854867,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","*** Bug 50295 has been marked as a duplicate of this bug. ***","*** Bug 50295 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,2,NA,"['*** Bug 50295 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-9952,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","*** Bug 50797 has been marked as a duplicate of this bug. ***",1373046915,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","*** Bug 50797 has been marked as a duplicate of this bug. ***","*** Bug 50797 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"['*** Bug 50797 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 50797 has been marked as a duplicate of this bug."
-9952,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","*** Bug 50797 has been marked as a duplicate of this bug. ***",1373046915,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","*** Bug 50797 has been marked as a duplicate of this bug. ***","*** Bug 50797 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,0,NA,"['*** Bug 50797 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-9953,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+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:
 
-Re-purposing this bug to talk about that. :-)",1367169998,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+(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)
 
-Re-purposing this bug to talk about that. :-)","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+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:
 
-Re-purposing this bug to talk about that. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph.', ""We've been thinking about putting a little icon in slugs and making them a different height/etc."", 'so it\'s obvious that they\'re not really ""there"" and are just places items can go.', 'Re-purposing this bug to talk about that.', ':-)']",NA,0,"This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph."
-9953,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+(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)
 
-Re-purposing this bug to talk about that. :-)",1367169998,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+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:
 
-Re-purposing this bug to talk about that. :-)","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+(In reply to comment #2)
+QUOTE
+QUOTE
+QUOTE
 
-Re-purposing this bug to talk about that. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph.', ""We've been thinking about putting a little icon in slugs and making them a different height/etc."", 'so it\'s obvious that they\'re not really ""there"" and are just places items can go.', 'Re-purposing this bug to talk about that.', ':-)']",NA,0,"so it\"
-9953,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+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.
 
-Re-purposing this bug to talk about that. :-)",1367169998,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+Example commandline:
 
-Re-purposing this bug to talk about that. :-)","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+curl 
 
-Re-purposing this bug to talk about that. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph.', ""We've been thinking about putting a little icon in slugs and making them a different height/etc."", 'so it\'s obvious that they\'re not really ""there"" and are just places items can go.', 'Re-purposing this bug to talk about that.', ':-)']",NA,0,"re not really ""there"" and are just places items can go."
-9953,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+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.
 
-Re-purposing this bug to talk about that. :-)",1367169998,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+Example commandline:
 
-Re-purposing this bug to talk about that. :-)","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+curl 
 
-Re-purposing this bug to talk about that. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph.', ""We've been thinking about putting a little icon in slugs and making them a different height/etc."", 'so it\'s obvious that they\'re not really ""there"" and are just places items can go.', 'Re-purposing this bug to talk about that.', ':-)']",NA,0,"Re-purposing this bug to talk about that."
-9953,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+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.
 
-Re-purposing this bug to talk about that. :-)",1367169998,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+Example commandline:
 
-Re-purposing this bug to talk about that. :-)","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+curl 
 
-Re-purposing this bug to talk about that. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph.', ""We've been thinking about putting a little icon in slugs and making them a different height/etc."", 'so it\'s obvious that they\'re not really ""there"" and are just places items can go.', 'Re-purposing this bug to talk about that.', ':-)']",NA,0,":-)"
-9953,"VisualEditor: Slugs should be more obvious to the user that they're not ""really"" blank lines","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+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.
 
-Re-purposing this bug to talk about that. :-)",1367169998,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-v7tsixpel4mikkpah73h","task_subcomment","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+Example commandline:
 
-Re-purposing this bug to talk about that. :-)","This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph. We've been thinking about putting a little icon in slugs and making them a different height/etc. so it's obvious that they're not really ""there"" and are just places items can go.
+curl 
 
-Re-purposing this bug to talk about that. :-)",NA,NA,NA,NA,NA,"True","c1",1,"True",NA,-10,NA,"['This is deliberate - the line is a ""slug"", allowing the user to insert text between the UL and the DL without creating a bullet and then down-converting it into a paragraph.', ""We've been thinking about putting a little icon in slugs and making them a different height/etc."", 'so it\'s obvious that they\'re not really ""there"" and are just places items can go.', 'Re-purposing this bug to talk about that.', ':-)']",NA,0,"We've been thinking about putting a little icon in slugs and making them a different height/etc."
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
+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.
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+Example commandline:
 
-In Firefox, edit any page in https://test2.wikipedia.org
+curl 
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
+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.
 
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0,"VisualEditor: Suggestion lists (of templates/links/categories/etc.)"
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**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
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0,"differ over time with the same input (e.g."
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**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
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0,"between browsers/users)."
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**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
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0,"Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \"
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**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
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}",1373635140,"PHID-USER-j5ma2nageni56xp567v5","PHID-TASK-v6t7ev5julnky6rafmtd","task_description","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**Attached**: {F11227}","VisualEditor: Suppression of Cite error in templates still paints a phantom./n/nScreenshot
 
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0," into input box."
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+**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.
 
-In Firefox, edit any page in https://test2.wikipedia.org
+https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
+https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206
 
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+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**: minor
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
+**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.
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
+https://en.wikipedia.org/w/index.php?title=Raising_and_lowering_indices&curid=11325244&diff=563062676&oldid=560490441
 
-In Firefox, edit any page in https://test2.wikipedia.org
+https://en.wikipedia.org/w/index.php?title=Regression_analysis&curid=826997&diff=563265603&oldid=561802206
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
+https://en.wikipedia.org/w/index.php?title=Bipartite_double_cover&curid=21241712&diff=563327691&oldid=554035797
 
-This suggests that at least one list of Template suggestions is absolutely incorrect.
+I'm not sure if this is related to an existing bug or a different kind of thing.
 
 --------------------------
 **Version**: unspecified
-**Severity**: minor
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
+**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.
 
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
-
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
-
---------------------------
-**Version**: unspecified
-**Severity**: minor
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0,"Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect."
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
-
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
-
---------------------------
-**Version**: unspecified
-**Severity**: minor
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
-
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
-
---------------------------
-**Version**: unspecified
-**Severity**: minor
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
-
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
-
---------------------------
-**Version**: unspecified
-**Severity**: minor
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0,"--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL"
-10782,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","In Chrome, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
-
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
-
---------------------------
-**Version**: unspecified
-**Severity**: minor
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406",1377199800,"PHID-USER-kqibbfgfpgocyzwe32lv","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_description","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
-
-In Firefox, edit any page in https://test2.wikipedia.org
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
-
---------------------------
-**Version**: unspecified
-**Severity**: minor
-**See Also**:
-https://bugzilla.wikimedia.org/show_bug.cgi?id=58406","VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)./n/nIn Chrome, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""
-
-In Firefox, edit any page in URL
-
-Click Transclusion, type 's' into input box.
-Result is a list of suggestions that begin with ""Succession box"" and ""South America""
-
-This suggests that at least one list of Template suggestions is absolutely incorrect.
-
---------------------------
-**Version**: unspecified
-**Severity**: minor
-**See Also**:
-URL","Low",25,1429301547,"PHID-USER-ydswvwhh5pm4lshahjje","declined","True","c1",3,"False","False",7,NA,"['VisualEditor: Suggestion lists (of templates/links/categories/etc.)', 'differ over time with the same input (e.g.', 'between browsers/users).', ""In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."", 'Result is a list of suggestions that begin with ""Smaller"" and ""Sectstub""\n\nIn Firefox, edit any page in URL\n\nClick Transclusion, type \'s\' into input box.', 'Result is a list of suggestions that begin with ""Succession box"" and ""South America""\n\nThis suggests that at least one list of Template suggestions is absolutely incorrect.', '--------------------------\n**Version**: unspecified\n**Severity**: minor\n**See Also**:\nURL']",FALSE,0,"In Chrome, edit any page in URL\n\nClick Transclusion, type 's' into input box."
-10783,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","*** Bug 70219 has been marked as a duplicate of this bug. ***",1416339245,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_subcomment","*** Bug 70219 has been marked as a duplicate of this bug. ***","*** Bug 70219 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,72,NA,"['*** Bug 70219 has been marked as a duplicate of this bug.', '***']",NA,0,"*** Bug 70219 has been marked as a duplicate of this bug."
-10783,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","*** Bug 70219 has been marked as a duplicate of this bug. ***",1416339245,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_subcomment","*** Bug 70219 has been marked as a duplicate of this bug. ***","*** Bug 70219 has been marked as a duplicate of this bug. ***",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,72,NA,"['*** Bug 70219 has been marked as a duplicate of this bug.', '***']",NA,0,"***"
-10784,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit). Not sure if this is a ""bug"" per se…",1387245600,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_subcomment","This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit). Not sure if this is a ""bug"" per se…","This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit). Not sure if this is a ""bug"" per se…",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,24,NA,"[""This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit)."", 'Not sure if this is a ""bug"" per se…']",NA,0,"Not sure if this is a ""bug"" per se…"
-10784,"VisualEditor: Suggestion lists (of templates/links/categories/etc.) differ over time with the same input (e.g. between browsers/users)","This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit). Not sure if this is a ""bug"" per se…",1387245600,"PHID-USER-ydswvwhh5pm4lshahjje","PHID-TASK-gi6xthiyrxw7c2mnmgvl","task_subcomment","This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit). Not sure if this is a ""bug"" per se…","This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit). Not sure if this is a ""bug"" per se…",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,24,NA,"[""This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit)."", 'Not sure if this is a ""bug"" per se…']",NA,0,"This is caused by the search back end that supplies the suggestions; I don't think it alters by user/browser so much as over time (though it's cached after the first request for a bit)."
-12293,"Add tracking category to pages with errors in ","An automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1365503760,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_description","Add tracking category to pages with errors in ./n/nAn automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Add tracking category to pages with errors in ./n/nAn automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Low",25,1467323599,"PHID-USER-t7ue4j3fnqznjjs4z5ef","resolved","True","c1",1,"False","False",-12,NA,"['Add tracking category to pages with errors in .', 'An automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"Add tracking category to pages with errors in ."
-12293,"Add tracking category to pages with errors in ","An automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1365503760,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_description","Add tracking category to pages with errors in ./n/nAn automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Add tracking category to pages with errors in ./n/nAn automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Low",25,1467323599,"PHID-USER-t7ue4j3fnqznjjs4z5ef","resolved","True","c1",1,"False","False",-12,NA,"['Add tracking category to pages with errors in .', 'An automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"An automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors."
-12293,"Add tracking category to pages with errors in ","An automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement",1365503760,"PHID-USER-tyjmn7xcw6s2b6rqagj7","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_description","Add tracking category to pages with errors in ./n/nAn automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Add tracking category to pages with errors in ./n/nAn automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.
-
---------------------------
-**Version**: unspecified
-**Severity**: enhancement","Low",25,1467323599,"PHID-USER-t7ue4j3fnqznjjs4z5ef","resolved","True","c1",1,"False","False",-12,NA,"['Add tracking category to pages with errors in .', 'An automatic tracking category for pages with errors in  (when parsed by texvc) would help finding these pages and fixing the errors.', '--------------------------\n**Version**: unspecified\n**Severity**: enhancement']",FALSE,1,"--------------------------\n**Version**: unspecified\n**Severity**: enhancement"
-12294,"Add tracking category to pages with errors in ","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].",1467323599,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[GERRIT_URL]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['I see nobody answers.', 'I am closing the task by myself.', 'If there is a problem, reopen it.', 'Closed as resolved by [[GERRIT_URL]].']",NA,1,"I see nobody answers."
-12294,"Add tracking category to pages with errors in ","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].",1467323599,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[GERRIT_URL]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['I see nobody answers.', 'I am closing the task by myself.', 'If there is a problem, reopen it.', 'Closed as resolved by [[GERRIT_URL]].']",NA,1,"I am closing the task by myself."
-12294,"Add tracking category to pages with errors in ","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].",1467323599,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[GERRIT_URL]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['I see nobody answers.', 'I am closing the task by myself.', 'If there is a problem, reopen it.', 'Closed as resolved by [[GERRIT_URL]].']",NA,1,"If there is a problem, reopen it."
-12294,"Add tracking category to pages with errors in ","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].",1467323599,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[https://gerrit.wikimedia.org/r/292576]].","I see nobody answers. I am closing the task by myself. If there is a problem, reopen it.
-
-Closed as resolved by [[GERRIT_URL]].",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['I see nobody answers.', 'I am closing the task by myself.', 'If there is a problem, reopen it.', 'Closed as resolved by [[GERRIT_URL]].']",NA,1,"Closed as resolved by [[GERRIT_URL]]."
-12295,"Add tracking category to pages with errors in ","The discussion was moved to [[https://en.wikipedia.org/wiki/MediaWiki_talk:Math-tracking-category-error|here]].
-",1467219463,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","The discussion was moved to [[https://en.wikipedia.org/wiki/MediaWiki_talk:Math-tracking-category-error|here]].
-","The discussion was moved to [[URL
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['The discussion was moved to [[URL']",NA,1,"The discussion was moved to [[URL"
-12296,"Add tracking category to pages with errors in ","No problem.
-",1467218718,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","No problem.
-","No problem.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['No problem.']",NA,1,"No problem."
-12297,"Add tracking category to pages with errors in ","Thank you. I have posted an edit request at that page on en.wiki.",1467210767,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","Thank you. I have posted an edit request at that page on en.wiki.","Thank you. I have posted an edit request at that page on en.wiki.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['Thank you.', 'I have posted an edit request at that page on en.wiki.']",NA,1,"Thank you."
-12297,"Add tracking category to pages with errors in ","Thank you. I have posted an edit request at that page on en.wiki.",1467210767,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","Thank you. I have posted an edit request at that page on en.wiki.","Thank you. I have posted an edit request at that page on en.wiki.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['Thank you.', 'I have posted an edit request at that page on en.wiki.']",NA,1,"I have posted an edit request at that page on en.wiki."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"We are talking about removing pages from category, so it can be done for your entire wiki and nothing else."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"1."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"2."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"4."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"5."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Save the page."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"6."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Open one page with a math error in good namespace for editing."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Make sure the category is there."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"7."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Open one page with a math error in bad namespace for editing."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Make sure the category is not there."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"8."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"If there is a problem, replace "":"" with ""-"" in the code and try again."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"9."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"When you are sure it works, run a nulledit bot on the current category content."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"10."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Done."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"First of all,SCREEN_NAME, you can't do it only in vector or only in your account."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Second of all, there is no link for this case help, because it's too obvious."
-12298,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467195164,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace for editing. Make sure the category is there.
-7. Open one page with a math error in bad namespace for editing. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace for editing.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace for editing.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"And the last parameter is the category name (you'll see it in the wiki editor in the page creation moment)."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"We are talking about removing pages from category, so it can be done for your entire wiki and nothing else."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"1."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"2."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"4."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"5."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Save the page."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"6."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Open one page with a math error in good namespace."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Make sure the category is there."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"7."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Open one page with a math error in bad namespace."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Make sure the category is not there."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"8."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"If there is a problem, replace "":"" with ""-"" in the code and try again."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"9."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"When you are sure it works, run a nulledit bot on the current category content."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"10."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Done."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"First of all,SCREEN_NAME, you can't do it only in vector or only in your account."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"Second of all, there is no link for this case help, because it's too obvious."
-12299,"Add tracking category to pages with errors in ","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",1467194961,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","First of all, @Jonesey95, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ","First of all,SCREEN_NAME, you can't do it only in vector or only in your account. We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.
-Second of all, there is no link for this case help, because it's too obvious.
-1. Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.
-2. Put there for example a code:
-{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]
-3. Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.
-4. And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment).
-5. Save the page.
-6. Open one page with a math error in good namespace. Make sure the category is there.
-7. Open one page with a math error in bad namespace. Make sure the category is not there.
-8. If there is a problem, replace "":"" with ""-"" in the code and try again.
-9. When you are sure it works, run a nulledit bot on the current category content.
-10. Done.
- ",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"[""First of all,SCREEN_NAME, you can't do it only in vector or only in your account."", 'We are talking about removing pages from category, so it can be done for your entire wiki and nothing else.', ""Second of all, there is no link for this case help, because it's too obvious."", '1.', 'Create a new page [[{{ns:8}}:math-tracking-category-error]] in your wiki.', '2.', 'Put there for example a code:\n{{#switch:{{NAMESPACENUMBER}]|1|2|3|118|2600=:|Pages with math errors}]\n3.', 'Where the numbers list is all namespace numbers where you want just a message, not a category - here, for example, talk, user, user talk, draft and flow.', '4.', ""And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."", '5.', 'Save the page.', '6.', 'Open one page with a math error in good namespace.', 'Make sure the category is there.', '7.', 'Open one page with a math error in bad namespace.', 'Make sure the category is not there.', '8.', 'If there is a problem, replace "":"" with ""-"" in the code and try again.', '9.', 'When you are sure it works, run a nulledit bot on the current category content.', '10.', 'Done.']",NA,1,"And the last parameter is the current name (you'll see it in the wiki editor in the page creation moment)."
-12300,"Add tracking category to pages with errors in ","I would love to do it myself (for everyone, not just in my own vector.js). @IKhitron, do you have a link to instructions on how to take care of it on en.wiki? Thanks.",1467177192,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I would love to do it myself (for everyone, not just in my own vector.js). @IKhitron, do you have a link to instructions on how to take care of it on en.wiki? Thanks.","I would love to do it myself (for everyone, not just in my own vector.js).SCREEN_NAME, do you have a link to instructions on how to take care of it on en.wiki? Thanks.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['I would love to do it myself (for everyone, not just in my own vector.js).SCREEN_NAME, do you have a link to instructions on how to take care of it on en.wiki?', 'Thanks.']",NA,1,"I would love to do it myself (for everyone, not just in my own vector.js).SCREEN_NAME, do you have a link to instructions on how to take care of it on en.wiki?"
-12300,"Add tracking category to pages with errors in ","I would love to do it myself (for everyone, not just in my own vector.js). @IKhitron, do you have a link to instructions on how to take care of it on en.wiki? Thanks.",1467177192,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I would love to do it myself (for everyone, not just in my own vector.js). @IKhitron, do you have a link to instructions on how to take care of it on en.wiki? Thanks.","I would love to do it myself (for everyone, not just in my own vector.js).SCREEN_NAME, do you have a link to instructions on how to take care of it on en.wiki? Thanks.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['I would love to do it myself (for everyone, not just in my own vector.js).SCREEN_NAME, do you have a link to instructions on how to take care of it on en.wiki?', 'Thanks.']",NA,1,"Thanks."
-12301,"Add tracking category to pages with errors in ","I meant one line in wiki code, @SalixAlba and @Jonesey95, not jawascript.
-",1467148543,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I meant one line in wiki code, @SalixAlba and @Jonesey95, not jawascript.
-","I meant one line in wiki code,SCREEN_NAME andSCREEN_NAME, not jawascript.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['I meant one line in wiki code,SCREEN_NAME andSCREEN_NAME, not jawascript.']",NA,1,"I meant one line in wiki code,SCREEN_NAME andSCREEN_NAME, not jawascript."
-12302,"Add tracking category to pages with errors in ","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",1467141776,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['It is a little annoying.', ""But I'm convinced it is worth the extra effort."", 'In time the number of false positives will go down and each page is re-rendered.', 'Some talk pages which discuss rendering errors  will remain.', 'If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.', 'jQuery( document ).ready( function( $ ) {\t\n    \tif( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {\n\t\t$("".mw-category-group a"").each(function(ind,ele) {\n\t\t\tvar title = ele.innerHTML;\n\t\t\tif(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") \n\t\t\t || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {\n\t\t\t\troot = ele.parentElement;\n\t\t\t\t$(root).css({""display"":""none""});\n\t\t\t\tconsole.log(ele.innerHTML);\n\t\t\t}\n\t\t})\n\t   }\n     }']",NA,1,"It is a little annoying."
-12302,"Add tracking category to pages with errors in ","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",1467141776,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['It is a little annoying.', ""But I'm convinced it is worth the extra effort."", 'In time the number of false positives will go down and each page is re-rendered.', 'Some talk pages which discuss rendering errors  will remain.', 'If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.', 'jQuery( document ).ready( function( $ ) {\t\n    \tif( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {\n\t\t$("".mw-category-group a"").each(function(ind,ele) {\n\t\t\tvar title = ele.innerHTML;\n\t\t\tif(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") \n\t\t\t || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {\n\t\t\t\troot = ele.parentElement;\n\t\t\t\t$(root).css({""display"":""none""});\n\t\t\t\tconsole.log(ele.innerHTML);\n\t\t\t}\n\t\t})\n\t   }\n     }']",NA,1,"In time the number of false positives will go down and each page is re-rendered."
-12302,"Add tracking category to pages with errors in ","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",1467141776,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['It is a little annoying.', ""But I'm convinced it is worth the extra effort."", 'In time the number of false positives will go down and each page is re-rendered.', 'Some talk pages which discuss rendering errors  will remain.', 'If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.', 'jQuery( document ).ready( function( $ ) {\t\n    \tif( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {\n\t\t$("".mw-category-group a"").each(function(ind,ele) {\n\t\t\tvar title = ele.innerHTML;\n\t\t\tif(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") \n\t\t\t || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {\n\t\t\t\troot = ele.parentElement;\n\t\t\t\t$(root).css({""display"":""none""});\n\t\t\t\tconsole.log(ele.innerHTML);\n\t\t\t}\n\t\t})\n\t   }\n     }']",NA,1,"Some talk pages which discuss rendering errors  will remain."
-12302,"Add tracking category to pages with errors in ","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",1467141776,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['It is a little annoying.', ""But I'm convinced it is worth the extra effort."", 'In time the number of false positives will go down and each page is re-rendered.', 'Some talk pages which discuss rendering errors  will remain.', 'If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.', 'jQuery( document ).ready( function( $ ) {\t\n    \tif( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {\n\t\t$("".mw-category-group a"").each(function(ind,ele) {\n\t\t\tvar title = ele.innerHTML;\n\t\t\tif(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") \n\t\t\t || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {\n\t\t\t\troot = ele.parentElement;\n\t\t\t\t$(root).css({""display"":""none""});\n\t\t\t\tconsole.log(ele.innerHTML);\n\t\t\t}\n\t\t})\n\t   }\n     }']",NA,1,"If its really a problem this bit of javascript in your vector.js will hide most of the talk pages."
-12302,"Add tracking category to pages with errors in ","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",1467141776,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['It is a little annoying.', ""But I'm convinced it is worth the extra effort."", 'In time the number of false positives will go down and each page is re-rendered.', 'Some talk pages which discuss rendering errors  will remain.', 'If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.', 'jQuery( document ).ready( function( $ ) {\t\n    \tif( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {\n\t\t$("".mw-category-group a"").each(function(ind,ele) {\n\t\t\tvar title = ele.innerHTML;\n\t\t\tif(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") \n\t\t\t || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {\n\t\t\t\troot = ele.parentElement;\n\t\t\t\t$(root).css({""display"":""none""});\n\t\t\t\tconsole.log(ele.innerHTML);\n\t\t\t}\n\t\t})\n\t   }\n     }']",NA,1,"jQuery( document ).ready( function( $ ) {\t\n    \tif( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {\n\t\t$("".mw-category-group a"").each(function(ind,ele) {\n\t\t\tvar title = ele.innerHTML;\n\t\t\tif(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") \n\t\t\t || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {\n\t\t\t\troot = ele.parentElement;\n\t\t\t\t$(root).css({""display"":""none""});\n\t\t\t\tconsole.log(ele.innerHTML);\n\t\t\t}\n\t\t})\n\t   }\n     }"
-12302,"Add tracking category to pages with errors in ","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",1467141776,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }","It is a little annoying. But I'm convinced it is worth the extra effort. In time the number of false positives will go down and each page is re-rendered. Some talk pages which discuss rendering errors  will remain.
-
-If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.
-
-  jQuery( document ).ready( function( $ ) {	
-    	if( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {
-		$("".mw-category-group a"").each(function(ind,ele) {
-			var title = ele.innerHTML;
-			if(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") 
-			 || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {
-				root = ele.parentElement;
-				$(root).css({""display"":""none""});
-				console.log(ele.innerHTML);
-			}
-		})
-	   }
-     }",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['It is a little annoying.', ""But I'm convinced it is worth the extra effort."", 'In time the number of false positives will go down and each page is re-rendered.', 'Some talk pages which discuss rendering errors  will remain.', 'If its really a problem this bit of javascript in your vector.js will hide most of the talk pages.', 'jQuery( document ).ready( function( $ ) {\t\n    \tif( document.title == ""Category:Pages with math errors - Wikipedia, the free encyclopedia"") {\n\t\t$("".mw-category-group a"").each(function(ind,ele) {\n\t\t\tvar title = ele.innerHTML;\n\t\t\tif(title.startsWith(""User:"") || title.startsWith(""Talk:"") || title.startsWith(""User talk:"") \n\t\t\t || title.startsWith(""Wikipedia:"") || title.startsWith(""Wikipedia talk:"") ) {\n\t\t\t\troot = ele.parentElement;\n\t\t\t\t$(root).css({""display"":""none""});\n\t\t\t\tconsole.log(ele.innerHTML);\n\t\t\t}\n\t\t})\n\t   }\n     }']",NA,1,"But I'm convinced it is worth the extra effort."
-12303,"Add tracking category to pages with errors in ","But @Jonesey95, you can do it in a minute by yourself.
-",1467135776,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","But @Jonesey95, you can do it in a minute by yourself.
-","ButSCREEN_NAME, you can do it in a minute by yourself.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,156,NA,"['ButSCREEN_NAME, you can do it in a minute by yourself.']",NA,1,"ButSCREEN_NAME, you can do it in a minute by yourself."
-12304,"Add tracking category to pages with errors in ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",1467130992,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['If possible, it might be a good idea to limit the namespaces to which this category applies.', 'For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g.', '""Category:Pages with archiveurl citation errors"":\n\n""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""', 'The error message still shows on these pages, but they are not categorized.', ""There is little point in categorizing someone's User sandbox page; it clutters the category with false positives.""]",NA,1,"If possible, it might be a good idea to limit the namespaces to which this category applies."
-12304,"Add tracking category to pages with errors in ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",1467130992,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['If possible, it might be a good idea to limit the namespaces to which this category applies.', 'For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g.', '""Category:Pages with archiveurl citation errors"":\n\n""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""', 'The error message still shows on these pages, but they are not categorized.', ""There is little point in categorizing someone's User sandbox page; it clutters the category with false positives.""]",NA,1,"For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g."
-12304,"Add tracking category to pages with errors in ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",1467130992,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['If possible, it might be a good idea to limit the namespaces to which this category applies.', 'For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g.', '""Category:Pages with archiveurl citation errors"":\n\n""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""', 'The error message still shows on these pages, but they are not categorized.', ""There is little point in categorizing someone's User sandbox page; it clutters the category with false positives.""]",NA,1,"""Category:Pages with archiveurl citation errors"":\n\n""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories."""
-12304,"Add tracking category to pages with errors in ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",1467130992,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['If possible, it might be a good idea to limit the namespaces to which this category applies.', 'For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g.', '""Category:Pages with archiveurl citation errors"":\n\n""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""', 'The error message still shows on these pages, but they are not categorized.', ""There is little point in categorizing someone's User sandbox page; it clutters the category with false positives.""]",NA,1,"The error message still shows on these pages, but they are not categorized."
-12304,"Add tracking category to pages with errors in ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",1467130992,"PHID-USER-7cpk77uy2iq7bxf6hac6","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ","If possible, it might be a good idea to limit the namespaces to which this category applies. For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g. ""Category:Pages with archiveurl citation errors"":
-
-""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""
-
-The error message still shows on these pages, but they are not categorized. There is little point in categorizing someone's User sandbox page; it clutters the category with false positives. ",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,156,NA,"['If possible, it might be a good idea to limit the namespaces to which this category applies.', 'For an example, see the Citation Style 1 error messages and categories on en.wiki, e.g.', '""Category:Pages with archiveurl citation errors"":\n\n""Pages in the Book talk, Category talk, Draft, Draft talk, Education Program talk, File talk, Help talk, MediaWiki talk, Module talk, Portal talk, Talk, Template talk, TimedText talk, User, User talk, and Wikipedia talk namespaces are not included in the error tracking categories.""', 'The error message still shows on these pages, but they are not categorized.', ""There is little point in categorizing someone's User sandbox page; it clutters the category with false positives.""]",NA,1,"There is little point in categorizing someone's User sandbox page; it clutters the category with false positives."
-12305,"Add tracking category to pages with errors in ","@Aklapper? Or maybe @Quiddity? Thanks.
-",1466776616,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","@Aklapper? Or maybe @Quiddity? Thanks.
-","SCREEN_NAME? Or maybeSCREEN_NAME? Thanks.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,155,NA,"['SCREEN_NAME?', 'Or maybeSCREEN_NAME?', 'Thanks.']",NA,1,"SCREEN_NAME?"
-12305,"Add tracking category to pages with errors in ","@Aklapper? Or maybe @Quiddity? Thanks.
-",1466776616,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","@Aklapper? Or maybe @Quiddity? Thanks.
-","SCREEN_NAME? Or maybeSCREEN_NAME? Thanks.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,155,NA,"['SCREEN_NAME?', 'Or maybeSCREEN_NAME?', 'Thanks.']",NA,1,"Or maybeSCREEN_NAME?"
-12305,"Add tracking category to pages with errors in ","@Aklapper? Or maybe @Quiddity? Thanks.
-",1466776616,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","@Aklapper? Or maybe @Quiddity? Thanks.
-","SCREEN_NAME? Or maybeSCREEN_NAME? Thanks.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,155,NA,"['SCREEN_NAME?', 'Or maybeSCREEN_NAME?', 'Thanks.']",NA,1,"Thanks."
-12306,"Add tracking category to pages with errors in ","It looks like this is fixed in T134872 by https://gerrit.wikimedia.org/r/292576 We can probably close this as a duplicate. ",1466691225,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","It looks like this is fixed in T134872 by https://gerrit.wikimedia.org/r/292576 We can probably close this as a duplicate. ","It looks like this is fixed in T134872 by GERRIT_URL We can probably close this as a duplicate. ",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,155,NA,"['It looks like this is fixed in T134872 by GERRIT_URL We can probably close this as a duplicate.']",NA,1,"It looks like this is fixed in T134872 by GERRIT_URL We can probably close this as a duplicate."
-12307,"Add tracking category to pages with errors in ","So we now seem to have [[Category:Pages with math errors]] on en wiki at least. ",1466630074,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","So we now seem to have [[Category:Pages with math errors]] on en wiki at least. ","So we now seem to have [[Category:Pages with math errors]] on en wiki at least. ",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,155,NA,"['So we now seem to have [[Category:Pages with math errors]] on en wiki at least.']",NA,1,"So we now seem to have [[Category:Pages with math errors]] on en wiki at least."
-12308,"Add tracking category to pages with errors in ","Hello, @Aklapper. It works. I think you need close this task as resolved.
-",1466629083,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","Hello, @Aklapper. It works. I think you need close this task as resolved.
-","Hello,SCREEN_NAME. It works. I think you need close this task as resolved.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,155,NA,"['Hello,SCREEN_NAME.', 'It works.', 'I think you need close this task as resolved.']",NA,1,"Hello,SCREEN_NAME."
-12308,"Add tracking category to pages with errors in ","Hello, @Aklapper. It works. I think you need close this task as resolved.
-",1466629083,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","Hello, @Aklapper. It works. I think you need close this task as resolved.
-","Hello,SCREEN_NAME. It works. I think you need close this task as resolved.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,155,NA,"['Hello,SCREEN_NAME.', 'It works.', 'I think you need close this task as resolved.']",NA,1,"It works."
-12308,"Add tracking category to pages with errors in ","Hello, @Aklapper. It works. I think you need close this task as resolved.
-",1466629083,"PHID-USER-t7ue4j3fnqznjjs4z5ef","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","Hello, @Aklapper. It works. I think you need close this task as resolved.
-","Hello,SCREEN_NAME. It works. I think you need close this task as resolved.
-",NA,NA,NA,NA,NA,"True","c1",3,"True",NA,155,NA,"['Hello,SCREEN_NAME.', 'It works.', 'I think you need close this task as resolved.']",NA,1,"I think you need close this task as resolved."
-12309,"Add tracking category to pages with errors in ","I think we would need comunity consensus for enabling the MathSearch extension in production... and a lot of cleanup work... sinc it's currently more desinged as demo/proof of concept.",1437662084,"PHID-USER-4sfm3grxdo6hnogm4iqe","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","I think we would need comunity consensus for enabling the MathSearch extension in production... and a lot of cleanup work... sinc it's currently more desinged as demo/proof of concept.","I think we would need comunity consensus for enabling the MathSearch extension in production... and a lot of cleanup work... sinc it's currently more desinged as demo/proof of concept.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,107,NA,"[""I think we would need comunity consensus for enabling the MathSearch extension in production... and a lot of cleanup work... sinc it's currently more desinged as demo/proof of concept.""]",NA,1,"I think we would need comunity consensus for enabling the MathSearch extension in production... and a lot of cleanup work... sinc it's currently more desinged as demo/proof of concept."
-12310,"Add tracking category to pages with errors in ","**physik** wrote:
-
-(In reply to Richard Morris from comment #2)
-> This error is made worse by the difference between the syntax used in
-> MathJax and texvc. In
-> http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/
-> Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-> a unicode character was used in a formula, the editor was probably using
-> MathJax so the error did not show up. There seem to be a few such errors. A
-> google search
-> https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.
-> org+-Talk%3A
-> can be used to find some.
-
-Bug 72240 will make it better again. I'll try to migrate this feature from MathSearch to the Math extension.",1413745226,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","**physik** wrote:
-
-(In reply to Richard Morris from comment #2)
-> This error is made worse by the difference between the syntax used in
-> MathJax and texvc. In
-> http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/
-> Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-> a unicode character was used in a formula, the editor was probably using
-> MathJax so the error did not show up. There seem to be a few such errors. A
-> google search
-> https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.
-> org+-Talk%3A
-> can be used to find some.
-
-Bug 72240 will make it better again. I'll try to migrate this feature from MathSearch to the Math extension.","**physik** wrote:
-
-(In reply to Richard Morris from comment #2)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-Bug 72240 will make it better again. I'll try to migrate this feature from MathSearch to the Math extension.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,67,NA,"['**physik** wrote:\n\n(In reply to Richard Morris from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBug 72240 will make it better again.', ""I'll try to migrate this feature from MathSearch to the Math extension.""]",NA,1,"**physik** wrote:\n\n(In reply to Richard Morris from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBug 72240 will make it better again."
-12310,"Add tracking category to pages with errors in ","**physik** wrote:
-
-(In reply to Richard Morris from comment #2)
-> This error is made worse by the difference between the syntax used in
-> MathJax and texvc. In
-> http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/
-> Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-> a unicode character was used in a formula, the editor was probably using
-> MathJax so the error did not show up. There seem to be a few such errors. A
-> google search
-> https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.
-> org+-Talk%3A
-> can be used to find some.
-
-Bug 72240 will make it better again. I'll try to migrate this feature from MathSearch to the Math extension.",1413745226,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","**physik** wrote:
-
-(In reply to Richard Morris from comment #2)
-> This error is made worse by the difference between the syntax used in
-> MathJax and texvc. In
-> http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/
-> Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-> a unicode character was used in a formula, the editor was probably using
-> MathJax so the error did not show up. There seem to be a few such errors. A
-> google search
-> https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.
-> org+-Talk%3A
-> can be used to find some.
-
-Bug 72240 will make it better again. I'll try to migrate this feature from MathSearch to the Math extension.","**physik** wrote:
-
-(In reply to Richard Morris from comment #2)
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-QUOTE
-
-Bug 72240 will make it better again. I'll try to migrate this feature from MathSearch to the Math extension.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,67,NA,"['**physik** wrote:\n\n(In reply to Richard Morris from comment #2)\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\nQUOTE\n\nBug 72240 will make it better again.', ""I'll try to migrate this feature from MathSearch to the Math extension.""]",NA,1,"I'll try to migrate this feature from MathSearch to the Math extension."
-12311,"Add tracking category to pages with errors in ","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.",1376979625,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.","This error is made worse by the difference between the syntax used in MathJax and texvc. In
 URL
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search URL
-can be used to find some.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,7,NA,"['This error is made worse by the difference between the syntax used in MathJax and texvc.', 'In\nURL\na unicode character was used in a formula, the editor was probably using MathJax so the error did not show up.', 'There seem to be a few such errors.', 'A google search URL\ncan be used to find some.']",NA,1,"This error is made worse by the difference between the syntax used in MathJax and texvc."
-12311,"Add tracking category to pages with errors in ","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.",1376979625,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.","This error is made worse by the difference between the syntax used in MathJax and texvc. In
+
 URL
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search URL
-can be used to find some.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,7,NA,"['This error is made worse by the difference between the syntax used in MathJax and texvc.', 'In\nURL\na unicode character was used in a formula, the editor was probably using MathJax so the error did not show up.', 'There seem to be a few such errors.', 'A google search URL\ncan be used to find some.']",NA,1,"In\nURL\na unicode character was used in a formula, the editor was probably using MathJax so the error did not show up."
-12311,"Add tracking category to pages with errors in ","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.",1376979625,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.","This error is made worse by the difference between the syntax used in MathJax and texvc. In
+
 URL
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search URL
-can be used to find some.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,7,NA,"['This error is made worse by the difference between the syntax used in MathJax and texvc.', 'In\nURL\na unicode character was used in a formula, the editor was probably using MathJax so the error did not show up.', 'There seem to be a few such errors.', 'A google search URL\ncan be used to find some.']",NA,1,"There seem to be a few such errors."
-12311,"Add tracking category to pages with errors in ","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.",1376979625,"PHID-USER-7hrs7wwclcldf7mm6a7o","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","This error is made worse by the difference between the syntax used in MathJax and texvc. In
-http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=569279227#Math_text_that_doesn.27t_parse_when_in_VE
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search https://www.google.co.uk/search?q=%22Failed+to+parse%22+site:en.wikipedia.org+-Talk%3A
-can be used to find some.","This error is made worse by the difference between the syntax used in MathJax and texvc. In
+
+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
-a unicode character was used in a formula, the editor was probably using MathJax so the error did not show up. There seem to be a few such errors. A google search URL
-can be used to find some.",NA,NA,NA,NA,NA,"True","c1",3,"False",NA,7,NA,"['This error is made worse by the difference between the syntax used in MathJax and texvc.', 'In\nURL\na unicode character was used in a formula, the editor was probably using MathJax so the error did not show up.', 'There seem to be a few such errors.', 'A google search URL\ncan be used to find some.']",NA,1,"A google search URL\ncan be used to find some."
-12312,"Add tracking category to pages with errors in ","**physik** wrote:
 
-This is already a feature of the MathSearch extension.",1365506334,"PHID-USER-ynivjflmc2dcl6w5ut5v","PHID-TASK-fr22j5swh5wt5gmpgdnh","task_subcomment","**physik** wrote:
+URL
 
-This is already a feature of the MathSearch extension.","**physik** wrote:
+URL
 
-This is already a feature of the MathSearch extension.",NA,NA,NA,NA,NA,"True","c1",1,"False",NA,-12,NA,"['**physik** wrote:\n\nThis is already a feature of the MathSearch extension.']",NA,1,"**physik** wrote:\n\nThis is already a feature of the MathSearch extension."
-13574,"Create a ""zen mode""/""Distraction free mode"" MediaWiki extension","Perhaps might be nice in MediaWiki core, but would definitely be nice as at least a MediaWiki extension, we should implement a ""zen mode"" capability from ?action=edit.
+I'm not sure if this is related to an existing bug or a different kind of thing.
 
-GitHub and it seems like the Cloud9 IDE both have this mode. It's demonstrated here: .
+--------------------------
+**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.
 
-In short, in the case of GitHub, it appears to be a bit of JavaScript that adds a ""zen mode"" button to the UI. When the user clicks this button, the non-essential page elements are hidden from the page, allowing the user to focus on the textarea (or other central input area) alone. Basically it reduces the amount of noise on the page in order to increase the signal.
+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=14501",1361595420,"PHID-USER-hyfm4swq76s4j642w46x","PHID-TASK-edwajw6htxppl743yg5e","task_description","Create a ""zen mode""/""Distraction free mode"" MediaWiki extension./n/nPerhaps might be nice in MediaWiki core, but would definitely be nice as at least a MediaWiki extension, we should implement a ""zen mode"" capability from ?action=edit.
+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.
 
-GitHub and it seems like the Cloud9 IDE both have this mode. It's demonstrated here: .
-
-In short, in the case of GitHub, it appears to be a bit of JavaScript that adds a ""zen mode"" button to the UI. When the user clicks this button, the non-essential page elements are hidden from the page, allowing the user to focus on the textarea (or other central input area) alone. Basically it reduces the amount of noise on the page in order to increase the signal.
+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=14501","Create a ""zen mode""/""Distraction free mode"" MediaWiki extension./n/nPerhaps might be nice in MediaWiki core, but would definitely be nice as at least a MediaWiki extension, we should implement a ""zen mode"" capability from ?action=edit.
+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.
 
-GitHub and it seems like the Cloud9 IDE both have this mode. It's demonstrated here: