s transparently.
> Perhaps this, and other whitespace issues (e.g. double
> spaces), should be flagged up to the user (with a wiggle underline?)
That would be one solution that is quite generalisable, but could be a great deal more work.",249608,4,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 52252 has been marked as a duplicate of this bug. ***,249605,4,,
-5.259584649534422,-5.252306490922509,-1.6705932999601532,-2.835956671541192,-1.4220853187507512,-1.5120835305789928,-0.5092691623744567,1.1652384160573521,0.604671203109812,0.39971172929135435,0.5021363314648543,-1.1318950907076317,-0.8091394212761551,-0.2907116615531702,-3.6849683143424303,0.2824368781687072,2.18073930037884,-2.501027709355754,False,c1,3,"With bug 50841 we now convert
[space]Foo
to
Foo
(previously Foo)
This is the correct behaviour.
We should be careful going do the road of automatically correcting what we believe to be typos. Perhaps this, and other whitespace issues (e.g. double spaces), should be flagged up to the user (with a wiggle underline?)",249601,4,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51509 has been marked as a duplicate of this bug. ***,249598,2,,
-4.308000562067698,-4.681353272945081,-3.399125242341743,0.8099466258880259,-0.6989517736542643,-5.4861839535580685,0.8254677863585105,-0.10791841234410665,1.389856784954208,1.5795758093258891,2.4642704978548315,-1.0411756706583652,-2.1885745408510067,0.31134226929700604,-1.0835594453378932,0.4461117213009347,1.1788516317675874,-1.3030240312425945,False,c1,3,"Without whitespace stripping (either in VE or Parsoid) and no nowiki, that text will become -formatted.
Quickly discussed with Gabriel on IRC. It is probably better fixed in VE since Parsoid doesn't have contextual information about where the space is meaningful or not.
If leading whitespace at start of line is desired by the editor, then VE should convert them to or if nowikis are acceptable, the spaces can be left alone. In either case, this kind of edits should hopefully be rare.",249594,2,,
8.025006173177202,-3.0348753778405158,1.2659340111885253,0.9361767270126418,1.1872519500656882,-7.350632102659114,-0.8584871924878232,5.823341212352084,-8.270233732256074,5.540689945975098,2.4181396213965076,-1.1586764367888818,-2.809772513412541,0.14038127520047605,-3.963241285024938,2.4166444107902407,-4.827887278283771,-0.3837027742305392,False,c1,3,"If VE can strip leading whitespace in paragraphs, that will eliminate these errors. Alternatively, Parsoid can do that normalization. Unclear where this should be done. Will discuss on IRC.",249587,2,,
60.14840487558653,-10.091185467818802,-0.07694526815823632,-2.5426243991839144,1.3654974845542434,-2.1210566473813763,-2.3151403871287153,4.708226566679536,1.1806678156893693,-0.05118984335533483,5.9874171380146795,-3.445053326976258,-4.089612468673911,4.507080695204488,-7.1704488241079005,8.056721135408408,8.03875197750063,-3.541606407428855,False,c1,3,and https://en.wikipedia.org/w/index.php?title=John_Altoon&diff=prev&oldid=564536250,249579,2,,
-7.9915535030040274,-0.037486697628443366,-2.9847506677165483,0.18197624775011612,4.104603574529005,-4.718353349964987,-4.205081925231372,18.344606357033673,6.748324638235622,-3.2950458572338697,-1.419151156762715,4.155282410435437,-7.731262049605132,4.638717400131947,0.7491308461560098,6.774736736559872,-1.4644570508332098,-1.2523064739217147,False,c1,3,Fixed and will get deployed in a few minutes.,249429,3,,
12.67454251875749,2.759355371130752,1.8902350976151725,0.11972523745946972,3.254493990954378,4.223726774546112,-6.69143634412236,-2.3195170097136586,3.9703795582968677,-0.8497468798542442,-5.430796125542786,-1.6129278310503308,3.1789173691955304,-3.172955390068176,-1.4855872630508364,-0.45368006598667776,-1.5520919817787668,-2.283429433990326,False,c1,3,"The resolution of Bug 51160 gives me hope. French Wikipedia transcludes Talk:.../Suppression subpages for some deleted articles.
https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial%3ARecherche&profile=advanced&search=Suppression&fulltext=Search&ns1=1&redirs=1&profile=advanced",249409,3,,
-2.9915914952376674,-4.895685245823204,0.5268378814756263,-0.4810653006622587,-4.069195596075019,-2.6791939721539,-5.720582191939682,-0.5322815335230836,1.358897632773154,-2.6039851416509547,-1.6946684314686968,1.1739948357658179,-0.7752762867040253,0.12109423722765089,-1.9323682813840133,-2.63339746549226,0.6607272429650244,-0.03185602840804069,False,c1,3,"@James, before marking this trivial, I hope you did an impact assessment on
1. https://de.wikipedia.org/wiki/MediaWiki:Newarticletext-0
2. https://es.wikipedia.org/wiki/MediaWiki:Newarticletext
3. https://fr.wikipedia.org/wiki/MediaWiki:Newarticletext
4. https://he.wikipedia.org/wiki/MediaWiki:Newarticletext
5. https://it.wikipedia.org/wiki/MediaWiki:Newarticletext
6. https://nl.wikipedia.org/wiki/MediaWiki:Newarticletext
7. https://pl.wikipedia.org/wiki/MediaWiki:Newarticletext
8. https://ru.wikipedia.org/wiki/MediaWiki:Newarticletext
9. https://sv.wikipedia.org/wiki/MediaWiki:Newarticletext
I know you didn't, because on at least one of those projects there is critical functionality in this message. Since you and O Keyes (on a different bug about missing interface messages) are being so rude, I'll let you find out the hard way.",249406,3,,
-1.294137883424769,8.382076353282823,-8.889750655959503,19.13693560209488,-5.93571933886588,-4.608374427662296,0.5306892179433973,-3.7736993342822758,2.626659382032983,0.7269139059641097,-0.5355801334527956,2.581147088078459,0.7752929657878616,-1.7750560245712246,-0.17055194224421655,-3.4943067736851563,1.8676661281289848,-2.620812299608609,False,c1,3,"(In reply to comment #1)
> This is something that obviously must be fixed before VE is enabled by
> default, which is planned for Real Soon Now(tm).
By default for whom on which wiki? It's been enabled by default on enwiki since 1 July for logged-in users and since 15 July for anonymous users too.",249404,3,,
2.1357241817375083,0.7334194752394012,4.488087095524303,2.408653127012677,11.2551732923048,-7.949959281712465,-5.520278843969912,-4.8191886952250735,6.839294692971972,11.585851598169395,6.121723558060886,0.4751933979197984,-0.7049006369737159,1.2834283577711585,-0.9435438797621429,-1.8590083871618845,0.43199630668683986,-1.681148385050696,False,c1,3,"This is something that obviously must be fixed before VE is enabled by default, which is planned for Real Soon Now(tm).",249401,2,,
-11.042743120190273,14.703581003641368,-12.448808887577533,-13.529375571516592,2.2466148666212415,8.790083055177664,2.3567139894004203,-0.17298276721551265,-2.7776582807863255,-2.4954984566777223,0.864764920919407,-4.005971385661128,4.687033843069756,-5.181523016868306,-1.5194564338126957,5.484108462216351,1.5057106713769584,3.6682859967599737,False,c1,3,"Confirmed, the link and language inspectors close on triggering the save dialog.",248279,59,,
-5.42347539527376,-6.794099440518205,10.774916597143873,-4.644853253945778,4.7215655701290835,5.6374512087441495,5.210089410971625,-2.089415340125425,-5.084919819417493,-1.0983675035244835,-1.3633351176164479,-1.5317128533149083,1.0592251188183397,-0.4417857735518763,-2.3154285360979334,-0.8380476030161526,-2.5045628953797925,-0.4639813476473975,False,c1,3,"Is this fixed now? I can't reproduce this any more. Clicking Save page closes the link inspector for me, and it seems to save the changes correctly too.",248274,59,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 63050 has been marked as a duplicate of this bug. ***,248268,48,,
-11.562242899080271,1.0427486338756697,0.27502434186211255,-9.920825946170389,3.533587821074015,-1.4751384839437875,13.431068559482975,5.806527425683367,-3.7822618296267088,-0.2510636823475041,-5.563639001053939,-0.49606968763529924,-1.3137777624052949,3.6987367130067774,4.827988457712429,4.179429795270665,-0.44507527613285147,0.7409263641020254,False,c1,3,"Same for context menu (e.g. focus a link, but don't open the inspector yet)",248263,2,,
-5.403231154032465,-15.635863340654474,15.16561743870164,-12.631640323231185,13.887018082424344,-18.316071692213495,4.731528536942394,-7.635191244854263,-5.642178477498855,15.232787438387165,12.98865235653092,2.728330645090586,-4.718352189173473,5.735192336871145,-4.72204696717649,1.8934092070483224,1.7767268634313693,-0.27242163720853263,False,c1,3,This is now merged and will be deployed later.,246849,4,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 52344 has been marked as a duplicate of this bug. ***,246840,4,,
-6.447990916286588,-6.102323404644721,7.049297451572675,1.3395667990229931,-13.387256376679836,1.8497434365327603,-8.284309017842602,0.7208040142716838,-1.136970513841629,4.389391981534253,-2.6196892714282427,-15.85142754375303,4.43836532544231,5.103246173073334,4.6261259736440765,-3.9666919848185906,-2.9863856882711226,10.665529139700075,True,c1,3,"I'm going to assume ""yes"" given testing.",246302,55,,
-5.765177833154617,-9.616582501374037,13.966852514502632,11.719086936251545,3.480186541587175,5.19431373562421,-15.950119569088457,-14.984009912860127,1.777610739993334,4.983700998247851,13.332981210984311,3.4585080253681317,4.249534554506351,-0.9262279755175267,1.5079592552163588,-1.3956793755257864,2.6153458212062692,-3.687921147242247,True,c1,3,Works for me... Has this been fixed since it was reported?,246297,55,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51984 has been marked as a duplicate of this bug. ***,246201,17,,
-5.403231154032465,-15.635863340654474,15.16561743870164,-12.631640323231185,13.887018082424344,-18.316071692213495,4.731528536942394,-7.635191244854263,-5.642178477498855,15.232787438387165,12.98865235653092,2.728330645090586,-4.718352189173473,5.735192336871145,-4.72204696717649,1.8934092070483224,1.7767268634313693,-0.27242163720853263,False,c1,3,This is now merged and will be deployed later.,246197,4,,
-11.413528305204863,4.103349369489269,-5.944073009814968,-5.698794229715055,0.4477658244661846,3.740596003240391,0.7974504381721168,7.88694875583154,3.3668572827155696,-6.552704989907303,-1.072483674689562,-3.2698841974202435,-0.18185329661283278,5.041926318762271,-2.015516015665219,0.504657968650466,-2.511618954594823,6.78779297845173,False,c1,3,"I can reproduce this by putting the cursor on a blank line (such as an empty page), clicking link inspector icon, then pressing key 'Esc'.",246178,3,,
-6.2774414171388875,7.46161143012089,-10.133427726777045,4.44301457236673,4.205563725486913,0.6288974214534466,-0.7131799890583004,7.659496666276883,7.7794444798267275,0.39696190011111643,-2.059436008572156,5.049981027555433,1.6708117965673432,-1.5347770169235293,1.55187940912782,0.8738028174366712,-0.34238054375277877,4.270344216364245,False,c1,3,"Bug 51415 is reporting the same JS error in the same component, with different steps to reproduce.",246171,2,,
-12.37329379940006,-5.457800134429913,3.608389107233312,14.430586122236177,-7.527516738621536,4.3987448945583765,-4.193108836674396,-1.0289733529526517,-1.4152188138490351,-1.999400811424663,3.913246278165826,3.798896892747277,0.718075448481986,2.1423814668378114,0.5777172972768532,-0.7547475491305589,-0.2540701287206855,-0.4927314426345544,False,c1,3,I've just tested this and can reproduce it except for comment 3 - in my test I was able to do everything except link and the save worked as expected.,246165,2,,
-8.12544930938182,-8.422878381097647,13.80305085881672,-7.455348204730469,5.534660542198571,5.932734683411756,1.2995927029089245,-6.196683781940479,-3.4127190011769146,4.627673555497939,1.2024353348503785,0.9220310703296919,-1.8991448904208723,0.7557214226841868,-1.0086544333663843,1.583887667423533,1.0821677073623177,-1.9591437571147865,False,c1,3,"It could be just be, but I run into this quite often. Every time it happens the interface crashes unrecoverably and all work is lost.",246159,2,,
11.62969754516847,2.0783259276765804,2.26599343446321,-3.6243467074939613,-5.734510609185026,-11.602062094752405,-9.54949865660548,-0.2638428963554773,-0.4280904328429113,-4.249560156494714,-2.1175780391945453,-2.55157759787464,0.13875693799840239,-1.0787216513557178,-4.214931348174506,0.37075811522437707,3.1755304939608826,-3.4183823405048437,False,c1,3,"Created attachment 12854
Screenshot of problem
**Attached**: {F11587}",246153,2,,
-13.390488220491445,-5.833541594129397,2.5747833450728743,2.8847704100664515,8.492259550669232,3.7915400773226935,1.7755931081315683,5.790207346091258,-2.9878330999245186,-6.097159088745558,-4.1432548460968714,-2.7628264741842417,1.543119954926392,-0.038847554951241925,-0.8657151286848637,0.050276532494556214,0.2793205446041741,0.5637601631346798,False,c1,3,"Note, this doesn't seem a race condition or anything. I'm giving it at least half a second to a second of time between each distinct action.",246147,2,,
-5.252895762920744,5.912021281437795,7.776545408718331,-14.039463877936297,-8.354532781543687,16.999594316120344,-2.536280901824922,4.053227133729001,-11.962413064448908,3.5377344170506877,4.645597341717462,3.1324914919110904,-6.442612349174171,4.143762761254053,-8.03505452146681,-1.2966805331326605,-11.498284646579215,-1.8400246359673247,False,c1,3,We will deploy this fix today.,246097,2,,
-2.7467775580015035,-1.9797911566377557,10.662724914221307,-4.333022545645987,-4.800753705649655,6.875568942714253,-10.107055098775982,4.967638004170535,11.08518884455681,-4.411512828282768,5.801112289354952,4.95852233412995,3.8114726456504844,-5.754391315526159,3.9649229405264297,-0.31610348058776383,-2.6793054040550626,6.929683439498419,False,c1,3,"(Sorry, if my last comment was unlcear:) Showing the full warning message, I mean.",246082,2,,
27.28083265935748,-1.1368740141380531,2.4281943716857137,2.163776993927538,-2.039579353642404,-2.822323386106543,-3.754856507878027,0.12862642710705988,-1.796803121759085,1.8658125598139925,-1.1954804424166126,-1.5972065314977493,3.266455852190414,-2.205667707429038,0.6915307277958576,2.5034926377281215,-1.8835729742520395,-0.2764792886383107,False,c1,3,"(In reply to comment #2)
> I don't think this is really what people want to be doing (regardless of
> whether HTML is being presented by this call or not). Take a look at filter
> 554
> on English Wikipedia (http://en.wikipedia.org/wiki/Special:AbuseFilter/554).
> Note how it triggers a message of abusefilter-top100. That causes the
> standard
> wikitext editor to display
> http://en.wikipedia.org/w/index.php?title=MediaWiki:abusefilter-top100 which
> explains what's wrong with the edit. That's what you need to display, not the
> short description (in this case ""top100 blog charts"", which doesn't mean
> squat
> to a new editor).
That's exactly what we're trying to do.",246074,2,,
-6.043378040571507,-5.066648757968263,-2.4957919108215343,-4.131310983292776,2.050435923659311,-1.3084557820168374,-1.2760311837933038,1.1392301847295145,-0.9506662353958911,1.4329644939867663,-1.8016773452288777,-3.1819795122961496,2.2589057950984284,-1.0327418226765992,0.834921796894943,0.5887355351487349,-2.2103536999367464,-1.6678662747766426,False,c1,3,"**kwwilliams** wrote:
I don't think this is really what people want to be doing (regardless of whether HTML is being presented by this call or not). Take a look at filter 554 on English Wikipedia (http://en.wikipedia.org/wiki/Special:AbuseFilter/554). Note how it triggers a message of abusefilter-top100. That causes the standard wikitext editor to display http://en.wikipedia.org/w/index.php?title=MediaWiki:abusefilter-top100 which explains what's wrong with the edit. That's what you need to display, not the short description (in this case ""top100 blog charts"", which doesn't mean squat to a new editor).",246055,2,,
-9.850131684682935,4.199394436127218,1.7155555768434523,7.428376755307534,6.6241499538701305,-3.8496277284617424,9.094879003049199,-3.101175930646032,2.8892982267196157,6.125321342176939,0.5362659533468871,-5.797507828566612,4.703779063329569,-2.430191175386595,-5.937240096303134,-4.097729987238452,-5.92775564978328,5.58538500263125,False,c1,3,That's because Status::getHTML isn't actually doing real parsing... going to look at this tomorrow,246047,2,,
-9.422912203968785,-4.220474169390279,-3.9319295740146503,-10.098667981758265,-1.328848270025273,-1.1550423867108854,1.2974491572792903,3.4519321731322434,2.5083603045840652,0.9780060600222305,-0.24786897667897834,-1.8637741830007903,0.5787198162620948,1.116847275647619,0.8533313208273743,1.8101629432235418,0.3586652321897702,-0.6879898381356813,False,c1,3,"we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.
whatever VE decides to do with ""illegal"" values is an interesting question, but TD itself should allow distinction between ""suggested values"" and ""legal values"", because the template syntax itself makes this distinction. VE can ignore this distinction or not, but TD should provide this information.
suggestedvalues serves templates that use {{#switch, and there are several different behaviors when param value is not present as one of the options:
- the switch may have #default, which does something useful - IOW, an ""unsuggested"" value is still legal
- it can have no #default, practically ignoring the value
- the #default can trigger an error.
TD syntax should allow better description of the behavior, so, e.g., ""template linting"" tools can detect and flag pages where a template with ""suggested values"" is used with ""unsuggested"" value: it can be an error worth flagging (2nd and 3rd cases above, where suggested values really means legal values), and not flag it for parameters whose behavior match the 1st case.
this is not a theoretical/hypothetical issue - such tools exist, and are used on several projects (see, e.g., Module:ParamValidator on hewiki and yiwiki).
peace.",1841604,444,,
-10.426127582251535,-1.2655692974393897,-1.6821567440228045,3.096481754417484,-0.5154658335898912,2.579370803686974,-0.09379312901210035,4.657540441396483,1.4118436028343317,1.7277053497497254,-0.6261061045061866,-0.530821786252778,0.8522497689162964,0.8887254301682368,1.0224352311056557,0.8890270752434595,0.616923444956199,0.9916372751361213,False,c1,3,"If I have a template that accepts three values for `foo` and renders an error if given anything else, would the user be able to enter a disallowed value using the ""suggested values"" user interface in such a way that they will not be surprised or dissapointed to see an error in the rendering – after they have saved their changes in the template dialog?
If I understand correctly, the ""suggested value"" feature is about autocompleting and/or recommending values in a free-form input field, and does not intend to add friction, make impossible, or ""power-user only"" to enter other free-form values, e.g. a basic HTML select field with no easy way to break out of it, unless the page had a pre-existing unexpected value that VE would need to accomodate for roundtrip. That is what an ""options"" or ""ENUM"" feature would be like in the end, I think.
Having said that, implementing suggested values first is fine of course. And depending on the kind of user experience you want to deliver, it might even make sense to provide both of these as part of the same single input type, with a toggleable restriction for free-form values (`allowOther: false`?). There are many ways to implement these two features differently and I don't think it's obvious that they'll be similar in logic and look, but it is also possible to make them similar/shared. Whether that's the best UX, I don't know. Something to consider I suppose :)",1684699,402,,
-6.458231295782042,-5.870954821003688,4.738557333205153,0.5591720666539004,2.0029083711219666,-1.1036034753782413,2.292750380793736,6.234290535292721,1.063306983398975,2.8753676139032196,0.28886434616577183,4.126526357791305,-1.7537677252023782,1.145858149643568,0.29764699527523764,-2.5002161759805133,3.0015928852150475,0.08634243111923379,False,c1,3,"This can most certainly be closed via {T271825}. While it's not 100% the same, it should be sufficient to resolve the relevant use case.",1684652,402,,
-2.478058072717162,1.4203421741137934,-6.948511267897414,-7.308619147421533,7.633050599896116,1.0593351729775513,-0.7720654957667392,7.136733122378836,1.8671384931004378,0.005817489751757776,1.3742892787688452,1.2363909623651734,-1.9762279704913461,1.1499990007204068,0.04186582661569016,1.6002820449812563,3.207615329812822,-0.10739467713356676,False,c1,3,">>! In T53375#5769182, @Tacsipacsi wrote:
> ```lang=json
> {""label"": ..., ""value"": ...},
> ```
where the label should be an InterfaceText (i.e. localizable) or null; like all other InterfaceTexts, plain string input should be accepted and transformed by the extension. The value is a plain string, of course.",1448999,346,,
-11.10977398709705,2.6910250223594474,-4.4984769118379795,8.197311627639264,1.7537849464906703,-0.4392356626336049,-0.8824955513925232,4.056854792577589,1.1208872768953615,-1.2273332751426036,2.277397039597649,0.15080004048171958,-0.03262018146314993,-0.35714073044219097,0.710012836997763,0.29447352366426793,1.9052061516291696,-1.637616489672408,False,c1,3,"A suggestion from https://www.mediawiki.org/wiki/Topic:Ve06hyihctm4p86n is to allow labels different from the actual value. It can be stored for example with:
```lang=json
""params"": {
""key"": {
""type"": ...,
""values"": [
{""label"": ..., ""value"": ...},
...
]
}
}
```
Maybe plain strings should also be allowed for convenience, which could be transformed by the extension to
```lang=json
{""label"": null, ""value"": ...}
```
form. (I’d also suggest to always display the actual value in addition to the label, but that’s up to the consumers, of course.)",1417852,339,,
-3.179043823807951,2.237268527603119,-1.5518901189670213,6.635120307123751,4.431403051316499,-0.2918595785155187,2.848590672898741,1.9323573238440699,3.761786610119276,7.576781459883938,0.6348953061274498,0.37456137887426255,0.007225085803428399,-1.6628497789164778,-0.10481481094000511,-1.6768658352788477,0.6346856364353487,-0.3447460712844559,False,c1,3,"Is this still on the docket? It's vital. Is there some other way of specifying valid string values in TemplateData (TD)? If not, that would appear to be a large oversight if TD is supposed to help users easily interact with template params",962355,227,,
-14.678859688883477,0.9765916527516119,-3.2646011362701914,8.187369636074868,-0.0987245354724724,1.7657355373283359,3.8486252851638607,12.280459882973691,4.065662809425622,8.453431458714677,3.0921405435093936,5.073337782895087,-2.8832246519480496,1.1154337325180206,0.9820930119841966,-2.531955900518516,4.481480468460499,1.0932783185757526,False,c1,3,It would also be useful to be able to use a set of possible values provided by some template/module.,957154,226,,
-9.021976334907954,4.142024761457737,-2.0564688616314624,-0.7496907130349211,2.566888834498119,0.909865486536086,1.495693818215674,5.465182054444309,0.449038279356178,1.0608203721827802,-0.7442402737899876,-1.6940245755927767,0.2568491277210092,-0.7131201387742904,-1.3913712210837546,-0.6622829822213991,-0.7580430667624375,-0.35494272005882443,False,c1,3,"That's something which would be extremely useful.
I'm currently working on a proposal for ease Wikitionary contribution through templatedata. Such a feature would for example allow to select word category (verb, adjective…). ",955145,225,,
27.453679772489586,-1.4478362818578017,-0.22454170597073242,-2.2691597420397613,1.829471660652537,5.979139965658426,-3.6748022578922273,0.8934754319266484,3.368021623152755,-3.045405035015298,-1.2792861915458476,-1.9329053790257644,-1.2189094404193435,-1.4047982240068733,-2.05774797232804,2.4601980532956187,3.212861507907188,2.1390074576160907,False,c1,3,">>! In T53375#564935, @Krinkle wrote:
> params: {
> ""key"": {
> ""type"": ...
> ""values"": [ .. ]
Seems a good way of specifying it, +1",444533,93,,
-9.394321032504845,-5.178908821173961,6.904366237236262,0.7437807226028728,-4.941805112073565,3.1953720866149666,1.5708396856313005,0.12979890596943347,-0.7361888820805293,-2.650607759935774,-1.5798206933812429,-2.1831349874910546,-0.7718216235389008,3.180668303896688,1.5896088620867816,1.4623690673169245,-0.7567744699477619,1.123717653442443,False,c1,3,"Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.
```
params: {
""key"": {
""type"": ...
""values"": [ .. ]
```
The upside is that this is easier to specify and validate.
An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).
Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.
But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support ""values"" only for string values.
As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.
The type-restricted implementation would look something like this:
```
params: {
""key"": {
""type"": ""options""
""values"": [ .. ]
```
And would treat them as type: 'string' with no further type association.
It also has the downside of having a ""param"" property (values) that only makes sense in combination with another. Making it slightly less intuitive.",1658584,396,,
-9.425552736485653,-3.089920409811949,-1.1211055485807213,-4.22924156765678,-4.080139318807277,-1.1815177942116062,-0.9604413341584479,1.135120845763963,1.078748481926951,-0.46794572934257994,-0.5903859746940272,-3.141886434824469,-0.3902534809937652,2.367734599359051,0.8752818158625053,0.8909351756514488,-0.07983570577626975,-0.48922640603005396,False,c1,3,"Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.
params: {
""key"": {
""type"": ...
""values"": [ .. ]
The upside is that this is easier to specify and validate.
An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).
Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.
But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support ""values"" only for string values.
As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.
The type-restricted implementation would look something like this:
params: {
""key"": {
""type"": ""options""
""values"": [ .. ]
And would treat them as type: 'string' with no further type association.
It also has the downside of having a ""param"" property (values) that only makes sense in combination with another. Making it slightly less intuitive.",434600,90,,
-9.425588229596881,-3.089973484460444,-1.1211271025181377,-4.229292972301796,-4.080182635887259,-1.1815252514112622,-0.9606463067480071,1.135038391347038,1.0785847160508943,-0.46796555315934807,-0.5904781089480087,-3.1419710054990118,-0.3904580863952245,2.3678057953551166,0.8755081417879347,0.8909230038137546,-0.07985656317865361,-0.4894015829904603,False,c1,3,"Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.
params: {
""key"": {
""type"": ...
""values"": [ .. ]
The upside is that this is easier to specify and validate.
An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).
Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.
But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support ""values"" only for string values.
As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.
The type-restricted implementation would look something like this:
params: {
""key"": {
""type"": ""options""
""values"": [ .. ]
And would treat them as type: 'string' with no further type association.
It also has the downside of having a ""param"" property (values) that only makes sense in combination with another. Making it slightly less intuitive.",244445,46,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 52754 has been marked as a duplicate of this bug. ***,244441,8,,
5.418296851902195,5.529768637276575,-6.555976988778183,-8.181878283921868,1.9689170919736156,1.7483633513858052,0.5616226574525829,2.6509922374086132,0.8006848401601394,0.7904728914257957,-1.2130836264813025,0.10988492197469224,2.9616374420302893,-0.1408357717644042,3.885258508073325,2.6052987158527348,1.1412172835920762,0.5563004794046349,False,c1,3,"(In reply to comment #2)
> Ping @TrevorParscal.
>
> Since wikitext template editing will always be possible, we can't (yet?)
> enforce values in VisualEditor. We can only suggest.
>
> E.g. if a template parameter ""foo"" is specified as values: ['a', 'b']. and
> wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while
> still
> being able to set it to a or b.
The ""normal"" way is a drop-down with the target of the drop-down being a free-entry text field that suggests entries (but does not block other entries).",244435,8,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 50760 has been marked as a duplicate of this bug. ***,244428,8,,
-7.9073957493911164,-3.988886411845847,-2.051182341938611,1.7777232379272725,-3.7615594163177297,0.16870967625400723,0.8697888434790446,-0.2721938312550096,-1.280068341963358,1.366735419576198,-1.494648188354918,-4.630152277385564,1.2827513537853799,5.383103962678112,3.5700263779873014,0.20592004714416756,2.470454234310196,-0.23854668343752783,False,c1,3,"Ping @TrevorParscal.
Since wikitext template editing will always be possible, we can't (yet?) enforce values in VisualEditor. We can only suggest.
E.g. if a template parameter ""foo"" is specified as values: ['a', 'b']. and wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while still being able to set it to a or b.",244420,8,,
10.36141459514952,-3.237862620558378,1.9291585624961325,-12.919168355859894,-0.3999368065140274,-5.483721965129999,-2.2942467908370157,2.693678222391718,1.5487410535337955,3.3575675610283016,0.9186594757635776,1.0649257569053159,9.546409006358346,3.520655541839875,5.485837031779433,-2.764862481946977,-1.2488637263009563,2.7148016523184615,False,c1,3,"See ""bug 50760 - Support suggested values"" which is quite similar.
https://bugzilla.wikimedia.org/show_bug.cgi?id=50760",244412,2,,
-11.509049471123063,-8.963446795253418,8.156445244755522,-2.0228598203210666,12.92616920102865,4.143151360285916,-2.9635323755411953,-1.287187890830357,-10.029800782904786,2.5438202944206134,3.754654030743253,-1.2888236525018573,-0.8242230421549395,6.130838538195039,-3.484421602885981,-2.6998260084996857,-7.042604236642956,-1.1835007157489756,True,c1,3,This is now done; we'll deploy this within the hour.,241917,2,,
-1.498698380070537,2.217534423407228,-12.238667975768626,10.486332274500556,-0.610015840249094,-5.0466717351331525,-1.9476772893964895,-2.504924663598213,8.487539993511858,1.6679501584203393,0.03952713897644622,2.509252325488487,-1.4818329585931163,0.3948232255332622,-0.7607566311297438,-1.9285625382093108,-1.0080665993377436,-1.5436262081266416,False,c1,3,Additional issue with empty HTML elements produced by templates (which are used for metadata) in bug 52551.,241551,5,,
-7.9915535030040274,-0.037486697628443366,-2.9847506677165483,0.18197624775011612,4.104603574529005,-4.718353349964987,-4.205081925231372,18.344606357033673,6.748324638235622,-3.2950458572338697,-1.419151156762715,4.155282410435437,-7.731262049605132,4.638717400131947,0.7491308461560098,6.774736736559872,-1.4644570508332098,-1.2523064739217147,False,c1,3,Fixed and will get deployed in a few minutes.,241545,3,,
-13.127557725086454,5.743685700240103,-5.605221307484769,9.390761195585954,-0.8120126718593381,3.367419175076627,0.5532108866611747,-5.522703502183677,-7.622018650663267,-10.817032512420582,-3.9512182577086175,8.571147890552496,-0.7310063614053182,3.8146267978872643,0.2248628856169832,-6.782730955283023,-1.2051755526531442,0.5762772538121017,False,c1,3,"I marked this as a dup of bug 49806, not dup of 51420.",241530,3,,
-5.739496772157976,1.5293820722134956,-4.981582750565979,-4.172714021100379,11.663236844125468,1.4909838514686324,4.731046109902943,-2.3696837812068385,-1.3374408310901515,-3.0493192113476466,-5.84149420279449,-3.147626967097248,3.9288158746326776,4.46341382703014,3.9120172918736147,-1.7818820518449683,-4.290293778181045,0.5988264621319117,False,c1,3,This is not the same as bug 51420. This specifically concerns templates which only produce 'metadata' in the VE-data-model meaning of the term.,241514,3,,
-10.262941876400182,3.5000807622368413,-9.037763109091998,-3.211531405292961,5.0807642241216335,-3.7897855833723746,-6.72443586456111,-6.205858030426466,-3.428413411824989,-0.18630657237871073,-2.059095158813521,1.7036529941812217,-3.329411471222237,2.296060110217957,0.1868727730887194,1.0903868296918096,-0.32439453618584335,-0.6276282215738869,False,c1,3,"
*** This bug has been marked as a duplicate of bug 49806 ***",241505,2,,
32.97996123574549,-1.3135503528696777,-1.6282142319842228,0.6997848210178983,6.4482318691130285,-1.1370551538487383,-4.611946016917717,-3.2382425550338625,1.1906188873188823,2.505303916900435,0.8976270993845774,-2.9999611264895085,0.3458438135571309,-0.6568745737657687,-0.9501357088609712,-0.08681281111983274,0.36514544807151206,-1.6162344586631194,False,c1,3,Another example given on WP:VEF is {{Link FA}},241499,2,,
-0.6556753009156608,-10.925010166347153,5.606996466526834,-0.749664070114406,-2.1644236897563873,-1.3043327799920252,-1.7368922082004747,2.897016175009069,0.8767215623124458,3.89489989738534,0.7680135492664053,-0.33948833952114565,-0.05159651027742029,-2.711690369101994,-1.2814421980826436,3.544799879984191,4.06163624380436,1.4749856566820951,False,c1,3,"To help searching: the cited examples are {{Use dmy dates}} and {{Use Australian English}}.
Increasing importance/priority because they can be deleted unintentionally, and it is very unlikely a new user will know how to add them back before they click save.",241490,2,,
-14.940021139734748,3.903373232343011,-11.414591654422992,17.951462770401648,10.783662147299271,-1.75035542714018,-3.091381626889543,5.871914883582709,-8.65485197217221,-5.614702418500849,-0.11233780410213168,-4.209843916648739,-0.8065964131087411,-2.0947059578734986,-5.636396987042646,1.6526605101464271,-4.055376206453773,0.23777020935864268,False,c1,3,No ability to track this down and no recurrence in over a year; closing.,399859,80,,
2.6111631755081817,-8.037294206949273,12.984425653275732,-10.46200359938181,-2.3111358547434806,-17.519330448770866,2.6356154593651286,7.6211637795174285,13.232321905803067,-10.660479605904019,0.2128346595490238,-1.8791211739981648,0.731504190020539,-5.909104972406724,-9.58467538187406,5.500128222703259,-0.6925080362354716,9.843042015236778,False,c1,3,Very odd corruption; assigning.,240387,1,,
5.217614637660201,-4.278158739990287,8.95749164997871,2.32626747806313,2.569391780391708,-1.6012675450854292,13.102794744423415,4.057545781544738,-9.163825543132226,-4.740265470293958,0.5940832606220496,-0.9157964774808587,1.412433358696287,1.0697711395561036,0.16016334519633624,-0.994550694720862,3.984486599968874,2.995178857211578,False,c1,3,"Trying to manually encode the dot again... It didn't work even on the URL field.
https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report%2E",240380,1,,
-8.722563261355338,-9.147696663815207,-4.28205532502851,4.431827435007216,0.3358248046737895,5.956399655523921,-4.63593558198736,3.105404540623047,2.3806365116019395,2.7469478612970546,0.2432699643955909,0.4022954080426908,2.622856572123748,-3.3977628125176977,2.762349397826034,0.2750386292189626,2.012274550136776,-2.3598276430392646,False,c1,3,"**wmdv** wrote:
I am unable to enter the correct url, because it ends with a period, which seems to confuse bugzilla.",240375,1,,
0.895433599574341,6.784998924306532,-12.800228844141774,-11.633391666531164,2.7104062141468948,6.206773248161596,0.32725821677797384,-1.999924395243534,-2.6053257081885812,-0.961951190631642,4.395695374441047,-0.5707988617338575,4.87904722293166,-2.2114042255572923,3.104137350431638,1.589813050110998,2.881184976387283,-1.7448419057108617,False,c1,3,"**wmdv** wrote:
The url for the support desk case is [https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Extensive_diff_report.]",240371,1,,
-8.63309431573216,8.956168205582674,-3.537534380557563,-4.154142400269304,1.0287795659409582,7.500643390930669,2.9315568673352015,-2.0026540889599795,-2.701836191978728,-5.2950558210569785,-1.8526098820580708,-4.006492094219425,-0.22952769678098006,-1.3362810804202103,-1.176333765598645,1.3345268288037082,4.71686029588956,1.4303252588666138,True,c1,3,"It's not a problem with right-to-left languages ;)
Removing the tracking bug.",239782,2,,
30.478935161781315,11.33850930018156,2.3377160110270623,-11.76891149597017,-2.3401188006499654,-0.21922891574861936,-1.4375183106458742,9.592033101283613,14.880310353795055,-1.043858106570546,1.1770934742882653,2.6956010102271204,-2.957105323780251,1.916125009723611,-0.7777614244063276,-0.711842374538953,-2.284745774048002,-0.9445037195355437,True,c1,3,"Permanent diff:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564362312#Issues_with_images",239777,2,,
-12.99911599542848,-3.8917035391866914,0.7586056162365455,15.208512716501803,-6.5914290952865695,11.586321374517414,-1.0842064915861727,-2.64072053815332,5.809364168468836,2.6340665402381918,0.2584617653801846,2.6442159293679213,-4.0477430066157325,1.9450812354874503,1.2532328531445778,0.10268031670387501,2.5988361080121547,-0.7602207720274152,True,c1,3,"I've copied his words verbatim as part of a long string of issues, but if it is helpful for you to see these word in context, it will be here until it archives:
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Templates_not_aligned",239774,2,,
-1.2490885179237212,10.301027405378132,1.988920714363143,-5.642452229828064,4.843003387988803,-4.023627791805968,-0.34722461930516957,-0.9773682212288725,-1.1482937836368452,1.3256680288992753,-4.691724686999589,5.775901940635836,4.395032142720515,-2.6243769024657064,5.385905253420391,2.539105680668504,3.0422655105413723,0.48966445403541536,True,c1,3,"Is bug 51295 a duplicate?
(In reply to comment #0)
> From English Wikipedia, John Broughton (♫♫) 22:40, 12 July 2013 (UTC):
An URL is always highly welcome.",239771,2,,
-12.601308917440361,3.3511214216869583,-9.540611518410676,-6.477304665045879,3.517828038949281,-2.096397263649312,-1.866181127831032,-4.75800201507842,0.6220593647344845,0.49094712952914854,-2.4737717390897704,2.24139856691328,-0.6687053568815136,-0.01554733109294415,-1.1302241290515704,-1.0510439158425524,1.383858627463782,2.502931054825948,True,c1,3,"51666 is the more general bug for relocating block items.
*** This bug has been marked as a duplicate of bug 51666 ***",239739,50,,
-13.377418020390103,-3.450287858944975,-2.845384038390238,-0.6450069505041292,14.008286734757704,-0.7188895328760818,-6.66823894306582,12.414171123727831,7.4403898784899205,8.80755936073829,-3.3887891324251824,5.532213577668913,3.5016572435696167,-1.8009420626801276,0.9990187832186441,-2.777296429081409,3.3019640434358952,2.040010246888333,True,c1,3,The initial plan is to try bug 65883 and see whether this is a good enough solution.,239737,47,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,True,c1,3,*** Bug 52657 has been marked as a duplicate of this bug. ***,239735,47,,
-10.244711419426231,-2.3091532466782407,3.7235220272940426,-0.11416998293776892,19.18587616652831,-1.3143324529293423,1.9505347106937254,3.8656063565260435,-7.083055649863786,9.037975744391359,-0.20633470289577227,-1.695597769429276,6.124773254749363,-4.6625552913211905,0.4940044446243501,-2.8807521169117414,-0.2535815051453432,-3.679246026760372,True,c1,3,So what is the way to fix this?,239731,24,,
-11.910802068841239,-3.889485170625747,-2.401450834684485,0.21040906653284353,2.5322713219536066,0.34260769605899455,1.1036682031499296,1.601590322422115,1.335514154013257,-2.808489120567649,-0.07865186219561027,-0.8623457976993167,-0.4581020869625072,0.11359899454810307,0.9040258095108449,0.5869161248650134,2.437661916805821,-1.5961965789516481,True,c1,3,"en.wp user Fram comments:
""it should be made impossible that when people move images in VE (which is very easy), they put it (inadvertently) in the middle of a word. Preferably, images should only be movable to spaces between paragraphs, but they certainly shouldn't be movable to the middle of a word. Example: [https://en.wikipedia.org/w/index.php?title=Egypt%E2%80%93United_States_relations&curid=15982815&diff=566841885&oldid=565660404]
The problem seems to be that when you move a picture, the final location is not decided by the upper left corner of the image (which seems more intuitive to me), but by the location of your cursor somewhere in the middle of the picture.""",239729,4,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,True,c1,3,*** Bug 52178 has been marked as a duplicate of this bug. ***,239723,4,,
-1.0663312908195417,2.627359308019429,-2.3551400088000056,3.609094675971429,2.2136407707157044,-2.77302220006872,4.633061240952616,-1.5126284235605518,0.632942313051778,4.694098006939521,-1.1952579837293946,-4.5775921369760955,2.000199384018691,-1.9747768395984293,-2.8007235520163802,1.4945443318672587,-3.3222964598490337,2.5431081472141943,False,c1,3,The mobile version of VisualEditor doesn't do text over-lays to avoid issues like this bug. Closing as INVALID now that work there is progressing.,238455,44,,
-11.630251592568111,8.538521262754422,-8.247808460020424,-6.543179083205496,17.917439059182268,8.539502568972928,-2.4467411806314567,3.6542058689946586,0.13955643771744553,-4.5707218450952425,-2.578029726875906,-4.100077818281133,3.7549032571421606,-4.457628279837248,-2.916109025041612,2.687770509009377,3.7769261280930513,5.858677907676173,False,c1,3,"Clicking the link icon at the top of the article works, which is a reasonable workaround. Dropping priority.",238451,1,,
-12.771067925343797,2.1093406230563705,0.21141302755450253,-3.2349362971596065,3.3380638750592198,7.603999425453342,3.230612876649266,0.08335413058172442,3.251180248482677,7.276538973777592,1.1655182298513778,2.7262086703067956,-1.1572452536140276,0.16482737466222552,3.2980847140325977,2.276217040208757,6.06850389048295,0.6530752413793937,False,c1,3,"The link icon moves when the text cursor is moved.
It is possible to zoom in to press the link icon, but it is very fiddly.",238444,1,,
4.32895207839584,6.258041085557455,6.0760161364271195,-13.579637135159741,15.896703125016934,-5.7276969277844945,-14.03461424848845,-0.7203886784339769,-8.560069483277278,-4.3136340403217845,9.804257831857049,5.000223753678585,8.357024725035252,0.7831409225661237,-11.063035830089934,-9.898037469146917,-7.333051290500573,9.708425037237836,False,c1,3,That was bug 52077. Closing this.,237406,15,,
-12.032324592025955,-9.791754936054657,5.253793577418957,-4.578648547747552,6.351659461001082,-3.6270231618462745,6.468943217264572,0.14500170465334122,6.949227803795845,-5.055735591200682,-1.5328248308737487,-0.0634704613941599,0.05776653835552148,-2.772470344876642,-1.8408423820909,-2.611507996189084,-1.9809613966096622,-1.577685752554283,False,c1,3,"Whatever is causing that (maybe just a misconfigured local filter?), it's most likely not related to this bug.",237398,3,,
3.638282438706046,1.454041547915585,-2.16156856458495,2.386204452845046,-4.630747119286404,-0.3251505874209393,-1.4841071216515616,-1.4965723481036584,4.728024722429237,1.055210133523392,1.9675224808884386,0.6377631080592217,0.4552813654243413,-1.542379248491858,0.06052341780511172,0.9891338953426736,-0.054029480955990944,0.22339498767487997,False,c1,3,"**swalling** wrote:
(In reply to comment #16)
> Much better, but I'm still seeing some issues:
>
> Looking for 500 ""blanking"" tags gives 498 ""blanking"" plus 2 labeled as just
> ""mobile edit"".
>
> http://en.wikipedia.org/w/api.
> php?action=query&list=recentchanges&rctag=blanking&rclimit=500&rcprop=user%7C
> comment%7Ctitle%7Ctags%7Ctimestamp
There are other strange things going on with tags...
http://en.wikipedia.org/wiki/Wikipedia_talk:Tags#Incorrect_tagging
Not sure if it's related or if we should file a separate bug for incorrect tagging. I think mobile is also suffering from this issue (or was as of yesterday).",237392,3,,
-8.991753949970239,-1.2632212039478645,-0.5838674078064137,-3.44922805213921,8.055225198920624,3.241160895007063,-2.881901409578308,2.2307092408149707,6.701823655400363,-0.9948579681472776,-2.6191044818508376,4.567134256471054,0.14784893243425845,2.755802706573233,3.9490904939009726,0.8768924879269613,1.8795901225360117,1.375291358449919,False,c1,3,"As a follow up, the two problematic tags I note in Comment 16 are both recent. It is possible they have a different underlying cause than the previous corruption. For example, this might represent a logic error in how the ""mobile edit"" tag is being recorded.",237386,2,,
-2.3989537556051745,-5.4341524638976875,3.792078664876354,-2.7501263922366235,-5.647069573931385,-8.6027837338847,0.6685966095952267,-3.6561165590222875,2.8028770122928304,-5.2197619103855235,-5.273188474971196,-7.007309087271144,5.977349307180753,7.18886762472279,-3.0859945710254113,-2.2921652465098323,-1.4198050745750648,8.381888154897641,False,c1,3,"Much better, but I'm still seeing some issues:
Looking for 500 ""blanking"" tags gives 498 ""blanking"" plus 2 labeled as just ""mobile edit"".
http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rctag=blanking&rclimit=500&rcprop=user%7Ccomment%7Ctitle%7Ctags%7Ctimestamp",237381,2,,
-1.5276635537007328,1.2289865648250196,-0.5369617224365082,15.895031538782066,-6.012655463725024,-2.9385948389588776,-4.992734438817264,0.06152737756583526,-0.8699021225835987,6.825410956097141,1.8445289820119821,0.3489223713628977,0.1767086326218763,-1.9437301990708877,1.6631355726892743,1.4796502272558036,-0.711547080265241,0.9785403751931185,False,c1,3,"(In reply to comment #14)
> Rebuild #2 of tag_summary has completed and the reports in comment 8 look
> better (to me). Anyone care to verify...
Appears to work for me, yes. Might be worth waiting for others to weigh-in, but from my POV this is fixed.",237376,2,,
-8.90424030205962,-2.8563457952772584,0.38860562046270397,8.711760130443674,-4.913526419215284,-5.214005720448792,-5.539478978289429,-3.2848140773555774,-2.1691177912553523,2.1814517329611824,-6.188004453075202,2.0143600260163526,5.200602238912786,-5.060096183711048,2.8608346340064035,3.39509359334377,-0.1796310542423869,-2.154006070115572,False,c1,3,Rebuild #2 of tag_summary has completed and the reports in comment 8 look better (to me). Anyone care to verify...,237372,2,,
-7.689264244438835,-1.7645189947122297,1.1422332181249084,-5.897912675377438,3.447283740835509,4.213802686873446,7.245814742341237,3.6072321137063574,1.0665003543394793,2.364549684826607,-2.1840174921625612,1.613803064834257,-0.041681940782661187,-0.7976658331152712,0.9805001985539876,-1.4629413550856323,-1.052760905735721,-0.04354805082815183,False,c1,3,"Btw, change_tag still looks complete to me; the binlog shows no problems there. Should just be the tag_summary rebuild logic at fault.",237367,2,,
-3.7032803006071995,5.526531473689715,-6.618153807973945,-1.9072748718180819,-0.0011939758331553918,-3.4515230896529783,2.4129435744951344,-0.44381847479812386,-0.11787930949582115,-2.573069032560416,5.263527532531285,4.9104704956483,1.3039776137393733,0.48585313474730785,2.7997237260367864,2.484264033964184,-1.8746684507358349,-1.0542024433675667,False,c1,3,"As Robert suggested in comment 8, the rebuild process missed some rows where revisions had multiple tags.
The script has been fixed and will run in batches on enwiki today. More info shortly...",237364,2,,
-13.735005617668529,1.1552149058461385,-3.4225322541292704,6.002154774417965,-0.42040996705573797,2.499800866234029,3.0687704484876566,2.601849566891469,4.439227476031199,-0.13654033635493068,1.670549509102262,0.532366453912573,-1.0665094664340293,-0.9619960207590367,-2.003559288970573,0.24353662403033027,3.0661021862614697,2.401947436310604,False,c1,3,"Am investigating whether the tag_summary rebuild was conceptually flawed with regard to revisions with multiple tags, or not.
Also dumping enwiki binlogs on a slave (we have a month's worth) and pulling out all change_tag queries. Will reload them offline and join against a copy of change_tag to prove whether it is, in fact, completely intact.",237358,2,,
-7.657685706354294,-4.073636124000384,1.064680462365247,0.35490803477167,1.5397276513672384,2.430740177099663,-0.9618105891438926,-5.079711895402767,-1.1015067769463702,1.9674084166372152,1.508665269630787,-3.2871129576089104,1.6512301027566938,-1.8435757666950567,-2.0795879429362376,1.418271006133012,3.1778980753244044,2.35843850140246,False,c1,3,"Lowering priority a bit since I don't there is data loss here (the table that was used to recreate the data still exists).
James: Assigning to you to determine the priority for getting around to fixing this data (since it affects VE related data, and you know what metrics are being tracked).",237353,2,,
9.015251394518774,8.974927253697835,-1.7925750646399046,-0.2332051659962584,2.1493541983145725,-2.5502733467014185,0.7233199526754959,-0.1905540133025282,-5.416333001480687,0.17741951394325017,-1.6752983149390177,2.7993606720936395,5.476500938025195,-3.9525845404483606,3.3173412160800284,2.758548537970999,-3.7150288580597253,-1.1871953524364165,False,c1,3,"(In reply to comment #8)
> A API query of 200 revisions tags as flagged as ""blanking"":
> While this query returns 200 entries, we find that only 188 of them report as
> actually having the ""blanking"" tag.
That's still the case today.",237348,2,,
-9.216550318112558,-3.682929203234867,-3.748433568779849,-2.9900755290884984,0.3626213260969955,-3.323073228323203,0.319029483999163,-0.5222415230972767,2.1803870968814616,-1.336125407125873,-0.9905973769160563,-2.4623936663697243,1.9451519867416005,0.5405419490452852,0.4318717505440204,-0.6866919366445954,1.0886254533040602,-0.24180938887510095,False,c1,3,"Sorry to add to what I'm sure was a bit of a hectic day for someone, but I'm still seeing lingering bits of corruption. Perhaps some sort of edge case that wasn't handled correctly by the rebuild? 99.9% of tags may be okay at this point, but here are some example that still seem to be errors.
A API query of 200 revisions tags as flagged as ""blanking"":
http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rctag=blanking&rclimit=200&rcprop=user%7Ccomment%7Ctitle%7Ctags%7Ctimestamp|ids&rccontinue=2013-07-12T22:20:40Z|589061595
While this query returns 200 entries, we find that only 188 of them report as actually having the ""blanking"" tag.
The remainder are things like
rcid=""590123889"" timestamp=""2013-07-12T14:30:16Z""
visualeditor
rcid=""590032703"" timestamp=""2013-07-12T00:33:31Z""
mobile edit
Where some other tag is reported but the expected ""blanking"" tag is not reported.
For another example of this issue see the API query for the ""visualeditor-needcheck"" tag:
http://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rctag=visualeditor-needcheck&rclimit=200&rcprop=user%7Ccomment%7Ctitle%7Ctags%7Ctimestamp|ids
This tag should only be applied if the ""visualeditor"" tag is also present, but we observe that most of the results have either ""visualeditor"" or ""visualeditor-needcheck"" but not both. A few entries even have other tags entirely.
What appears to have happened is that rebuild didn't correctly handle cases where a single revision was subject to multiple tags. Instead it looks as though the rebuilt table applies at most one tag to each of the historical revisions. Most of the time that's okay since few revisions actually have multiple tags, but it still leaves a bit of corruption and missing data on the rare cases when a revision is expected to have multiple tags.",237342,1,,
-0.6426664238767019,-5.01810726827142,1.9118642252278857,-7.361727913214028,-1.916992085441418,-9.415877413928973,5.353540325257258,-4.841474346873665,-2.144044023109987,-4.9104701220305795,0.9695364639309925,-0.35897109565405483,2.365480227175432,-2.139275597683434,2.8347572192628894,1.8315742050960766,-5.317003277807948,-2.495527797456404,False,c1,3,"**swalling** wrote:
Just checked this on-wiki as well. Seems fixed.",237336,1,,
-14.547040434660811,8.734513399605014,-10.134590469665186,-25.52291269291706,0.1468046515786412,7.256739197533857,2.535730857239411,-4.525364619418021,26.021375030630143,20.000376569101256,3.9383339468791796,6.121262581206172,1.1709195415655156,0.022521138588202705,4.886702438642744,-0.9797901349003282,2.127629843615374,4.465826485638594,False,c1,3,enwiki.tag_summary rebuild is complete.,237329,1,,
-4.877305948105782,0.2799651191971275,-6.330548899806681,-0.8067006374967782,3.649263681333629,-0.4449216975275121,0.11017871725376693,3.2353494426791523,1.9331930510194988,-4.370165935868725,1.6151645443385665,0.16386919152297263,-0.15352202827303296,0.08132519294989704,-0.958874287659212,0.6357950140614581,0.1748248439701713,1.2927323894385832,False,c1,3,"Firstly, we've determined this problem occurred due to an (apparent) bug in pt-online-schema-change when using a combination of:
- A table without primary key
- A table with unique indexes that all include nullable columns
- An unfortunately timed REPLACE statement in normal db traffic
Posc does online table alteration by:
- Creating a copy of the table with altered schema
- Setting triggers on the original table to keep the copy updated
- Copying data across using a batch process
In this case, posc set a DELETE trigger on tag_summary using a poor UNIQUE index (ts_log_id) with low cardinality and a nullable field. Then during the batching process, an external REPLACE statement with ts_log_id=NULL caused many too many rows to be deleted in the temporary table being altered. Given that many rows in tag_summary have ts_log_id=NULL, the table was massively reduced in size.
Now to the fix:
We've checked the other wikis and found no problems; only enwiki was affected.
Furthermore, only enwiki.tag_summary was affected. We've verified that enwiki.change_tag is complete and did not suffer the same problem. This was based on:
- Index cardinality and table size information collected before running the schema migration
- An investigation of the events in the binary log surrounding the migration period
Currently we are rebuilding tag_summary based on change_tag data. That will complete within 30 mins at the time of writing this comment.",237322,1,,
-6.377542415087899,-8.85013719858004,-4.8780579160201185,-15.256817516245274,-10.801306174590565,-9.09533025660468,-4.953334929150011,7.110936475169001,9.537209353875694,-3.2891758145852994,-0.380908650862239,-11.46363634942323,4.876416834847531,14.501071008990133,2.4310271687781464,-0.8372999776436711,-1.150247491477343,-0.360866041038685,False,c1,3,"(In reply to comment #3)
> Was it determined if any other databases apart from en.wp's one were
> affected?
Not sure. The wikis that potentially may have this issue are:
+ 'arwiki' => true,
+ 'commonswiki' => true,
+ 'cswiki' => true,
+ 'dewiki' => true,
+ 'elwiki' => true,
+ 'enwiki' => true,
+ 'enwikisource' => true,
+ 'enwiktionary' => true,
+ 'eswiki' => true,
+ 'etwiki' => true,
+ 'fawiki' => true,
+ 'fiwiki' => true,
+ 'frwiki' => true,
+ 'hewiki' => true,
+ 'huwiki' => true,
+ 'idwiki' => true,
+ 'itwiki' => true,
+ 'jawiki' => true,
+ 'ltwiki' => true,
+ 'mrwiki' => true,
+ 'nlwiki' => true,
+ 'plwiki' => true,
+ 'ptwiki' => true,
+ 'rowiki' => true,
+ 'ruwiki' => true,
+ 'simplewiki' => true,
+ 'svwiki' => true,
+ 'trwiki' => true,
+ 'ukwiki' => true,
+ 'zhwiki' => true,
cf bug 40867#c6",237314,1,,
-5.662602616390045,-5.685740045350185,-1.028842278915478,2.6309346046624444,-0.6722699641220649,1.0457674997021567,1.1446988321165215,-0.7945000319513879,7.287617945116013,-0.2254680672671716,14.471791859606817,7.562135863051254,-0.30216781808027093,2.465141296983046,0.20137353857465046,-7.847522438206301,2.0694965257704854,-1.1059441617590244,False,c1,3,Was it determined if any other databases apart from en.wp's one were affected?,237308,1,,
-10.728320131707525,-5.103143295810382,-4.464233386991802,0.17913488521070065,6.71225882651305,4.241906595862112,-1.3477271402057838,1.419229843572316,-1.0993382643586616,-1.9340762766222954,-1.431386281325857,-2.474802625849585,0.9802600351743167,-1.8687424131334103,-1.2048753073055012,1.0531037639676644,1.5513342071147511,-0.10852268272258225,False,c1,3,"Sean and Asher narrowed this down to a problem with the schema change tool that we use, and are working on a strategy to fix the data. This looks like it's strictly a db-related problem that once fixed should stay fixed (assuming we don't try another similar schema migration before an upstream fix is made to the migration tool)",237301,1,,
1.2036876101754919,-14.777186779993869,-3.0476051669349737,7.871046615166938,-2.6325124911485096,-10.125009753553114,14.806927798206447,-6.450906522682906,0.8525332597799515,2.8941739169602494,-2.7389137533787316,-3.660243077486889,0.7948470400361636,-4.745059511893179,-0.09171281823116662,-0.6531235851008734,1.6834251452618103,-5.0078370284171605,False,c1,3,"Only seems to affect en.wp right now (works correctly on pl.wp and mw.org, for example).",237297,1,,
-12.957654045297481,-1.750377748927189,-3.063611944876767,-4.434346623404311,15.373890256697138,4.053996106038074,-4.048456602118489,1.2614628389991207,3.2069845840887963,-4.600692679308056,-0.9434023759607744,-1.9578689989123217,0.9446902188889599,-2.904898921947438,-4.701410729807722,2.0899979019551416,-3.618175544526849,4.058488886715258,False,c1,3,"Looks like those pages have unclosed big/small annotations, which are wrapping all the content beneath them, including the categories. This is triggering a previously unseen bug in the converter.",236193,1,,
-10.262941876400182,3.5000807622368413,-9.037763109091998,-3.211531405292961,5.0807642241216335,-3.7897855833723746,-6.72443586456111,-6.205858030426466,-3.428413411824989,-0.18630657237871073,-2.059095158813521,1.7036529941812217,-3.329411471222237,2.296060110217957,0.1868727730887194,1.0903868296918096,-0.32439453618584335,-0.6276282215738869,False,c1,3,"
*** This bug has been marked as a duplicate of bug 49873 ***",236146,1,,
51.06081625372884,62.86355102286544,49.00556268556856,-15.365653121670178,7.037151951881635,-3.992077034242298,38.18784358388994,-6.396004725747968,-2.068540096026057,-5.665304496187064,-3.072647677054126,2.315345719199967,0.4854824391190884,1.3603371509518205,1.0924633291801453,-3.386098687391972,4.863282263744287,-1.5875925965991458,False,c1,3,Also https://en.wikipedia.org/w/index.php?title=Frobenius_solution_to_the_hypergeometric_equation&curid=16407499&diff=563915886&oldid=561013687,236140,1,,
-5.819165139997819,-6.087583836948394,3.257127344393491,1.4389395668368703,0.22858022357533692,1.824277473871458,-0.8871728389826679,-0.4562330699124758,-1.5241220745198985,-1.3431470240113028,-0.2546796909868383,-1.8723474746734272,0.2516024548759712,0.1043665918108867,-0.8587892932136607,0.9789047881576862,-0.1147632816354351,1.1271492205952067,False,c1,3,"Er. What?
As I've said, VE is an extension. Parsoid is an extension. This page is not /based/ on a MediaWiki namespace page, it is based on a string in the i8on file. To fully deprecate it we'd have to find some way of fully suppressing it or remove it completely from mediawiki. This would impact not only wikis with the VE but also those without.
Moreover, I'm not sure how users receiving less information is, in this case, a problem, because I've never seen any evidence users actually /read/ those notices. I've been patrolling new pages since 2010; if CITE YOUR SOURCES! and the warning not to submit copyrighted content actually worked to inform people, I'd be the first person to hold my hands up and go ""this is awesome and we need to keep it"". They don't.
I'm (again) closing this as a WONTFIX. If people want to dispute that, I welcome an argument made as to how having this message helps - or how silently removing it from every Wikimedia instance of MediaWiki and dealing with the resulting fallout would be an effective use of our time.",232197,3,,
-6.513346568348019,-24.44959492437118,7.161889684169616,3.579915051581006,-2.1148189060684466,-1.5171298704592893,9.803870664369482,-8.172458319784365,13.11936729906608,1.3925414725940497,0.895612108571386,4.383446773695753,-2.1398679579062003,-2.6776681867073853,2.4506248660636647,-2.678924722841369,7.5350960965492115,-1.1664289967210513,False,c1,3,"major->minor, so it isnt red anymore.",232194,3,,
-5.893176315327425,-4.526804495835712,-6.897451248989647,1.4244308719399559,0.6677088012274233,-2.955105734877142,1.3417311619186005,-0.38573085853120215,-0.5359956170164031,-1.6697189080191244,0.9405162377001515,-0.08693113760300086,-1.553082218391845,-0.5418843351106973,-0.8576321732196246,1.003354960375796,-1.0271191584429715,-1.143637494797054,False,c1,3,"The problem doesnt go away because itwp deleted the message.
It still exists in enwp, zhwp, viwp & hrwp, of wikis above 100,000+ pages. (fawp has a commented out notice) Possibly many more with less pages.
These messages informed the user about verifiability as well as licensing issues.
But if this message is truly not going to be displayed in VE, and VE is the way of the future, then the message should be deprecated and deleted from those wikis (with community consensus after explaining to them they have no other option :P), otherwise user's of VE receive less information then those of SE, for good or ill. (in this case this bug should be moved over the core component)",232192,3,,
-4.860168974866412,2.9386737577221282,-4.135443765272099,3.695996789277297,-0.38633860963854616,2.5724087540247993,1.5307706412961881,1.454606388272928,-2.282051318599556,-4.13644430928166,1.4950973270419317,0.14189286522709033,2.7916033954097843,-2.3211570710475384,0.16534318415380778,1.5716713795124653,0.18055847792055843,2.0583833516927634,False,c1,3,"(In reply to comment #7)
> Resolved-Fixed -> Resolved->Invalid. What the?!
Not a bug in VisualEditor; itwiki had removed the licence information from the, err, licence information message. Oliver fixed it by editing the message to restore the licence warning. No changes to VisualEditor actually happened.
We are fixing enough bugs without having to artificially inflate the numbers of how much we're doing. :-)",232189,3,,
25.25257826804446,-3.4197244267424143,5.702309267959569,-7.518029422566506,6.246866012540181,-5.606760820582933,-9.71679399646095,4.735812740012483,-3.6346588892169516,-6.476331137533578,-0.35017743555032776,-4.846717963333615,-0.2990221219227167,-1.5379912880538076,-1.9422249069764983,2.5341022972096576,1.341714175243822,-4.331711117437717,False,c1,3,Resolved-Fixed -> Resolved->Invalid. What the?!,232183,3,,
-1.3776441937132438,0.33969922740808833,5.838489541824199,-15.790104874897278,3.100143388346222,-8.072853388439748,5.554231677257436,-0.4265930057980878,-5.17193336676865,-7.011378486326599,3.0755733288829985,-2.7367542194755,-1.534664753014801,-1.0761902236476772,-5.603623624899449,-1.0980462083214833,-5.985020638133123,-4.433186522156249,False,c1,3,Now resolved; thanks all :).,232176,3,,
1.2179519137159076,4.026887778222946,5.685501709573218,0.762205910867241,-10.51404849464352,7.250511531934752,6.678382174513187,-9.456544672024268,1.227643840624544,-2.815516245594802,-1.2316137535165383,0.5642025571275431,-3.8523728664592713,1.3753764581893704,1.1147237019567635,2.016023727324562,-0.5139119739994441,-1.6550015242352845,False,c1,3,"PS: (it's not just about copyright, in our case) http://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Legal_issue:_copyright_and_other_warnings_must_be_visible_above_the_%22save%22_button
Thanks.",232170,3,,
-7.872131111737828,-4.682078003384158,3.3812752021690446,5.498595362942696,-2.4590631013952953,3.4753037012499277,2.8014235327627883,1.4608481217672002,-2.423086196057608,1.2147711881586298,-0.03322347026418426,-0.47089457830377235,0.70760480679809,0.5092502402704511,1.7280865266354866,-1.3712611349368378,0.0902512983659666,-0.3069237119568662,False,c1,3,"On the Italian Wikipedia that does not happen though, please tell me if there is anything I can do to fix this ASAP.
In the past some users at itwp asked if the copyright/warning notices we use (https://it.wikipedia.org/wiki/MediaWiki:Wikimedia-editpage-tos-summary ) under the edit windows could be removed for experienced users, but the option was always discarded on the basis that a more prominent notice than the one in the footer was necessary for ""legal"" reasons (yes, people don't usually read or understand what it says anyway, but certainly they can't complain they don't get enough notice about this. And we do care a lot about this topic.)
I can see the notice when I try to save on en.wp, although it is so small I almost can't read it with Monobook on Chrome, but it does not show up on it.wiki, and since I don't want patrollers to report additional copyright issues after deployment, I'd ask for advice about this. Thanks.",232164,3,,
-5.8301364187174665,-2.3717672722447674,-2.212186475431245,2.9824399659334,3.1559981829172727,2.653095285988311,-1.0288500838812045,1.214374246162154,1.3239803980114873,-1.8964319271651515,0.09846122632644794,-1.378800063507338,-0.2499941309994691,0.5996882320143155,1.0924169811155449,1.2262887116678503,2.507474020022527,-0.5652190670056618,False,c1,3,"I'm confused. Because it's part of MediaWiki core, it can't be overridden or suppressed by an extension? A large chunk of the extensions we practically use suppresses elements of core. This would seem to conflict with the practical use and applications of our extensions. Similarly, removing it would be rather unfair to, for example, third-party users, since VisualEditor and Parsoid are both extensions. We do not include them in the standard tarball.
The message is useful, yes, but replicated in a form in the VE. If you've used the VE, you'll know the ToS link and release are given prominent placement, not ""tucked away down the bottom of the page"". The only occasions on which the ToS /are/ tucked away down the bottom of the page is in namespaces and wikis without VisualEditor/Parsoid....where editpage-head-copy-warn is not suppressed.",232158,2,,
-2.7652843239284266,-0.5491527448331617,-3.9743062430832232,2.562685789570132,9.75702589030206,2.615249251272644,-3.886946399637357,1.7231426586271223,1.4617036930458636,2.2480214135934595,1.5915277557290197,-0.853790420673362,-0.6289225313450837,1.972572617383977,0.5867920493372307,-0.8196625512054454,2.350232249498796,-0.5928676368951908,False,c1,3,"This message is part of mediawiki. If the message is extraneous, it should be removed. Until that happens, it should be part of the VE.
On English Wikipedia this message includes ""Encyclopedic content must be verifiable."" and a prominent link to the ToS, which is otherwise tucked away down the bottom of the page.",232152,2,,
-9.597168966261503,-7.04967628059672,2.904957243740899,-2.991724610009328,0.1822943090485687,3.849142484032921,0.3862233346730637,-1.781206859108015,0.18110660288342628,-2.771386372781691,0.7670334606818647,-0.8671585945610012,0.39232203509339936,-0.2635882448866511,0.8708992452311843,0.420694123442114,1.9870150037820389,-1.2842503341717393,False,c1,3,"I would argue that this is somewhat extraneous; I don't think anyone actually reads it. Really it exists primarily so that when someone whines about their content being deleted, we can go ""there was a notice"". It undoubtedly did serve a purpose on the Good Old Days {{cn}} when our terms of service were written on a napkin - but these days Geoff and the team have produced the rather concise and all-encompassing https://wikimediafoundation.org/wiki/Terms_of_Use, which covers (amongst other things) copyright infringements and redistribution - and is linked to in the interface.
I appreciate it's slightly more obscure than an editnotice, but it's also the approach taken by every other website on the planet: users can't really claim they were ignorant unless we're the only place on the internet they visit.",232145,1,,
-6.631354319312126,-4.766450055460362,6.708834830794961,3.023049888225364,-0.9651798457457685,1.2392842476020753,0.32096416979459264,-0.41032123185545133,-3.355655026022001,-4.465275419454006,-1.1087074519233555,3.2038599302007507,5.131954805831313,-0.06461611926409416,0.7857630976492,1.6670178726432947,-3.792184414093775,4.9008953280300425,False,c1,3,"I was NOT able to reproduce it following the steps from comment 0 and of comment 3, and also in the case of comment 4. Moreover, I don't remember seeing any new reports on this, so I'm marking this as FIXED (but I don't know which code change fixed the bug).",231053,17,,
-8.23078016911007,-5.390987041405095,10.800020574963423,-6.999333064597697,0.2550112449525628,4.757071944855397,5.303883447912005,-1.20109130683678,-1.3845915534742907,-3.2570523365673196,-0.0025935909545757863,-0.7392381976296871,-1.0727074561603906,1.1271820427533872,-4.495211194174088,0.4379006029856405,-1.153267523437092,6.169850557498666,False,c1,3,I can't reproduce this now using a simple test case. Has it still been happening on pt.wp?,231047,17,,
9.992110999795033,10.848712416051534,16.11271657710209,-14.368365123670165,10.126729788067337,-7.3247047959462535,5.8481571025458035,-1.2803945739645455,-7.9408671536876465,-9.676810491992907,13.818468151577257,2.021572406363152,4.86426625390885,1.278812640771066,-4.138070235353849,-7.715549715179426,-6.9285065064690885,-4.681953731818444,False,c1,3,"This happened again:
https://pt.wikipedia.org/wiki/Haroldo_Palo_Jr.?diff=36430552",231043,2,,
-2.975479799533244,-6.367349372935381,-0.48324432960652697,-3.113207152005966,6.982231110570963,-0.6687541065805718,-2.843593041146529,1.4087884073340113,-1.1079697928920735,4.123630748430012,1.3481554929467165,1.4095576372520444,-0.9480262747225956,0.5129521618505777,-1.645244489234497,0.3249798337213421,1.6069800789279214,1.404061306211664,False,c1,3,"This little devil can be reproduced at
https://pt.wikipedia.org/wiki/User:John_Vandenberg/demo?veaction=edit
(remove the template at the top and click save)
It is a very common case, and VE cant be used safely on pt.wp until this is fixed.
Im guessing this is related to the high priority Cite enhancement bug 51260.",231038,1,,
17.21949996283309,-0.7851623825238949,-3.642966336042102,1.274491794791178,4.897367400229378,-2.3734246094688327,-1.969317754355643,2.975717903238949,-1.3004435220389075,-3.8440844854326337,-2.22381613884933,-0.9014320368142323,1.5991613382199885,-2.1218400628216605,0.661369676883488,1.7598325761112288,0.33464272975797893,-2.5682344772443324,False,c1,3,"(In reply to comment #1)
> I don't know if this is relevant, but the same code ""{{referências}}"" expands
> to something different on [[pt:special:ExpandTemplates]]:
>
> Edite a página toda em vez disso."">Referências
> group="""">
>
>
> Direct link:
> https://pt.wikipedia.org/w/index.php?title=Especial:
> Expandir_predefini%C3%A7%C3%B5es&input=%7B%7Brefer%C3%AAncias%7D%7D&contextti
> tle=Associa%C3%A7%C3%A3o+M%C3%A9dico-
> Esp%C3%ADrita+do+Brasil&removecomments=true&removenowiki=true
That's pretty much the same as the expansion that leaks into the article, except for the first tag (the ).",231032,1,,
8.444803706185144,-14.830819898050743,-10.377586274349662,-7.4982204075895,-4.309156591216507,0.6592919215271991,-1.6068981523199835,4.3712494399502395,6.062661475825346,-0.14540870795495842,-0.7455685361247455,-2.8648410032587712,0.003749601797936375,2.2871587802185243,-0.3611981426253994,-0.16984920151150096,-0.12490588996046427,-2.6584363483133635,False,c1,3,"I don't know if this is relevant, but the same code ""{{referências}}"" expands to something different on [[pt:special:ExpandTemplates]]:
Referências
Direct link:
https://pt.wikipedia.org/w/index.php?title=Especial:Expandir_predefini%C3%A7%C3%B5es&input=%7B%7Brefer%C3%AAncias%7D%7D&contexttitle=Associa%C3%A7%C3%A3o+M%C3%A9dico-Esp%C3%ADrita+do+Brasil&removecomments=true&removenowiki=true",231028,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,True,c1,3,*** Bug 51165 has been marked as a duplicate of this bug. ***,255495,8,,
-9.610634932299458,-6.54882376301196,-5.79043666770879,1.4563366547518442,9.049927879975662,-6.707613141915214,-1.9087728541377373,3.852197476147074,4.05947009966217,0.8139479012799979,3.645274907069936,2.65815267444629,-5.581836698837117,5.007220409189175,0.33264536300142744,3.3706279258781455,-1.381203196949917,-0.8678505239362644,True,c1,3,"This is now done (as a single-click-to-insert), and will be deployed in the next few minutes.",255489,2,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51112 has been marked as a duplicate of this bug. ***,255245,2,,
8.494384844498017,-2.285995820041661,11.125192090148163,-10.05437507418582,-2.8228892991493613,-13.641540217906725,-10.691104755337097,15.257333675502242,19.17647780640084,-4.837455400628744,3.7818694473363985,0.8976151761051341,-5.055965820747044,3.293763968007257,-4.961641384121931,4.030452822881033,1.4432315619299225,-3.8310194105046387,False,c1,3,Fixed and merged.,255238,2,,
12.980691033260912,2.801552974284565,-8.414039761341988,-13.607596561154063,-1.245838260417429,1.966906915071469,1.4317888822265417,-1.4379756033521676,1.4110558664849469,0.47946007601989926,-1.3343318866256295,-1.332712551076646,2.281197974641329,-0.002216263072229996,0.4111587692683787,-0.3624309147364979,-0.6543668679213815,-1.2655042604923068,False,c1,3,"**weskaggs** wrote:
Further observations: the ""pawn"" has utf-8 hex code E2 99 99. The multibyte characters that provoke this behavior are either of:
devangiri letter LA, unicode 0x2354, utf-8 hex E0 A4 B2
devangiri letter BHA, unicode 0x2349, utf-8 hex E0 A4 AD",255217,1,,
-9.223961153809947,-4.875890450804873,-1.3505200520253164,-1.4559170326624837,2.7954070259924713,0.8151271573772263,1.8345159690363673,-1.3897718708905873,-1.1222571904855236,-2.130385040126394,-1.3506201861717373,-2.531434483847157,0.17259724743285032,0.04407571268044297,-1.0252542674623708,-0.40019069066126933,1.0697294078798367,-1.2855944785862907,False,c1,3,"Turns out that it happens when inserting any character after the link, but only at the position immediately after the link (so the second character isn't pawned because there's something (the first pawn) between it and the link), and only if there is multibyte text in the same paragraph preceding the link.
The article's first and only paragraph starts with ""Jabhala (Hindi:जभाला) is..."" and so this bug affects every link on that article. But it doesn't affect any links before जभाला (there aren't any right now but you can create them), and if you use Enter to break the paragraph after the Hindi text, it doesn't affect any links in the second paragraph either.
Assigning to Ed because this is a multibyte issue.",255207,1,,
-11.757422110743626,1.2503155809473974,-9.697472370953367,-2.2892985313351257,8.412533680802103,1.8650431846773152,-0.3540592160552425,1.3613040963764114,1.9870424220245038,-1.9655175321501233,0.39542059937774365,2.7523313993381864,-0.4942560824747573,-0.00958317741196213,2.5967076174237125,1.1325693813273139,1.836521043609997,-0.5846385472562092,False,c1,3,"**weskaggs** wrote:
In case it may be helpful, the character produced is a white chess pawn, unicode 0x2659 (html ♙). This character is produced if any character is added immediately after any of the three links in the first sentence, but not if a character is added after a link in the second sentence. If the Hindi text in the first sentence is deleted, then characters entered after a link produce the correct result.",255199,1,,
-12.569513705435414,0.10560673527827191,-10.217763371722757,0.6545858714798776,9.08580747244546,-1.6369140374405404,1.9626223578475788,2.088618481450954,-0.1998098235168917,-6.998260334879664,1.825941683187351,-1.8138139126097292,0.5588604096413645,3.372713236857372,1.202221214509164,2.171671629371094,-0.6646308999884692,-1.0679976271812186,True,c1,3,"This has now been moved from the ""options"" section to a small rubbish bin icon next to each template's name, and duplicated in the control section in the left navigation bar.",254945,35,,
-3.3971471573670797,-7.843654178192073,6.637451220503969,-4.358240638684091,-4.279824067049522,5.96778028111347,3.0919729372868563,-1.4868384893161468,-0.5737754381316837,-0.9709824293363152,-3.658530893299909,-3.3874718240771005,1.7989325990700493,4.969036855526679,5.164501845687227,3.9288498921959567,1.0302358108754979,0.1420225824212613,True,c1,3,"We don't like the ""Options"" label either (it's a standard part of dialog panes in VE, but here it doesn't add anything).",254938,4,,
-10.262941876400182,3.5000807622368413,-9.037763109091998,-3.211531405292961,5.0807642241216335,-3.7897855833723746,-6.72443586456111,-6.205858030426466,-3.428413411824989,-0.18630657237871073,-2.059095158813521,1.7036529941812217,-3.329411471222237,2.296060110217957,0.1868727730887194,1.0903868296918096,-0.32439453618584335,-0.6276282215738869,False,c1,3,"
*** This bug has been marked as a duplicate of bug 51140 ***",253838,2,,
-7.9726962196261955,-7.752807437442439,10.115418912328924,-11.950612648879858,-6.207610362579356,10.627192113613347,-9.191299427801786,-5.468554419861902,-4.53966989461368,7.063862328347835,6.066091209051205,0.4570663594912485,-5.59366202532844,8.02067182751505,-3.589016635032902,2.679380640663209,-1.4914892327637308,-0.582345526217634,False,c1,3,This code has been fixed and we'll get it deployed tomorrow.,251893,1,,
-10.262941876400182,3.5000807622368413,-9.037763109091998,-3.211531405292961,5.0807642241216335,-3.7897855833723746,-6.72443586456111,-6.205858030426466,-3.428413411824989,-0.18630657237871073,-2.059095158813521,1.7036529941812217,-3.329411471222237,2.296060110217957,0.1868727730887194,1.0903868296918096,-0.32439453618584335,-0.6276282215738869,False,c1,3,"
*** This bug has been marked as a duplicate of bug 50645 ***",249201,2,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 52205 has been marked as a duplicate of this bug. ***,247503,12,,
-1.5384342841321557,17.120811912291373,-5.517672635774355,11.175246080428474,-6.446420313296979,-10.752482036262993,-4.922107982792812,1.1921516322036245,12.368139477730137,-4.008653720452509,-10.180996445072548,15.732812740072351,-5.073674762611089,5.663845162300524,0.7692354389748077,-3.3258377098329963,-7.58402125756302,-1.1295555252861704,False,c1,3,Same as bug 52205?,247498,12,,
-7.381024054199214,0.8189850432453909,-1.495962894244209,2.010165889888974,0.8970174510310898,-1.3215948057870577,1.0164008395344606,5.9593247902325714,-4.719461626182995,1.0771289867770042,-3.1708889069400397,0.4460833966140987,0.97860493010486,-0.6236900715473702,-1.415688420782519,-1.2848110599779266,3.4107458997222846,-1.1669069957143305,False,c1,3,"Steps to reproduce:
1. Reduce the screen width until the toolbar wraps. You should now see something like attachment 12793
2. Reduce the screen width even more until the screen is too narrow for the HD stylesheet. The skin elements will animate and you'll end up with something that looks like attachment 12794.",247492,1,,
2.1799844807948734,2.2541329936060457,-2.7607578308514036,-3.8199884115463423,-6.205480607583825,-8.507583281194254,-6.0542916661502355,2.2527660490573522,10.01296879205965,-2.4381935214605797,-2.4868665814979813,0.07702401143184279,-1.6314105528054041,0.034907961847515434,-1.9378010933772445,1.3069235110579567,-0.5736706465275484,-3.676196838366693,False,c1,3,"Created attachment 12794
protrudes into wrapped toolbar in non-HD stylesheet
**Attached**: {F11631}",247485,1,,
8.592051995610289,2.882311101056203,-1.0422246614700295,-2.6891101981023677,-5.539208050161108,-8.583067189983588,-2.7819726245633847,-4.037486236604584,1.0055646484879797,-2.8006201135328226,-2.6809347836796222,-3.2677919074850976,-0.13168968579982554,-1.5512745023610077,-3.877402169477632,2.68008357418604,1.2150475598482369,-0.9102605749722001,False,c1,3,"Created attachment 12793
Wrapping toolbar correctly pushes down in HD stylesheet
**Attached**: {F11630}",247475,1,,
1.6324075679865553,23.162983714700644,-5.309860615740625,15.70842798768462,-9.571566366947442,-5.271167311547785,-0.5696087308532576,-2.8472597772208217,0.24510434263050684,-2.453247142980369,6.4210303391482935,0.19045255404678318,10.935479532773723,-10.059992682030694,6.659001797560937,4.409792513792973,-1.001294308888681,-3.020033252031485,False,c1,3,Per report. ;-),245509,48,,
7.6545057545375865,2.937187790219941,-12.12588799866155,5.7833533806724535,-9.604230427494144,-9.41744218884741,-4.626310687668811,-6.105476573901617,-2.442657340223451,-4.291227726659959,-4.435676517603669,9.587414557355661,2.9153956202958495,-1.3337383455572402,5.825371901856394,4.820982726363463,-4.42580231387649,2.0893130849862733,False,c1,3,"Confirmed fixed in 1.24wmf7, yay :-)",245502,48,,
9.968203295100645,6.01697052319631,-4.4581707382571185,6.8729920701225335,3.567993355194975,-3.6688412377434627,1.049617392393646,-4.969607867147084,-0.30809677367616184,-1.4123329559442381,-0.39125969246946957,-0.32431785111809486,0.2500809020759718,-0.9015615830506507,0.9355476855227183,3.3039545103852253,-0.8405501322462162,0.14948393860155296,False,c1,3,"(In reply to Krinkle from comment #3)
> Both VE and TemplateData should address this in their own way. Both parties
> need to do something.
>
> 1) Resolve redirects in API interaction:
> - TemplateData should have an option to resolve redirects in the given
> titles (like action=query). the mapping will be added similarly to how we
> normalise titles.
This is a built-in feature in ApiPageSet, which is used by ApiQuery modules, as well as by ApiTemplateData. When enabled, passing &redirects to the request resolves redirects.",245467,46,,
-10.467663729711273,8.664954469108615,-2.846479571813385,-5.677014995805782,13.218624317526004,1.776687307731244,6.488461929197131,-1.562989874579975,8.435478122508712,2.7655073260592635,0.243203417675113,2.920667505814527,0.7923012118129096,-0.8012966287285642,1.707731626158484,-0.9417392120537076,-2.447958490681418,-0.8506097501241214,False,c1,3,This is still a major usability issue with templatedata as template redirects are quite common. Any update?,245461,44,,
-9.59362505162353,-3.1721587321482314,0.5170790977848658,12.699150504378144,-1.8463940209366783,6.438023962300786,1.2351689467595701,1.0841082139926805,0.1689242974837346,-0.8193604794781395,-0.03846581379123193,1.093484735506573,-2.649487890970793,0.48846694315161243,-1.172683531690328,0.4553211230927978,-1.2050049136691223,-0.7782562060826468,False,c1,3,"We have been talking about returning more metadata like the list of used templates from the PHP preprocessor, and use that for dependency tracking. Even with that info I'm not convinced that we should attempt to directly skip redirects in Parsoid, as that would add a lot of complexity and unexpected behavior.
It should not be that hard to handle this in TemplateData itself, and to me it looks like the best place to do it.",245455,37,,
-2.42921335341794,-5.600484790307453,0.2519810515392904,-2.6911989964363716,1.4492635880467741,-1.3321663983666543,-1.0345490680218408,1.9957136313251338,-1.142301142814956,0.13107097893803488,-1.1939912212181771,-1.4267680980842603,0.4168160106240757,-2.446886519113863,-0.17408831444034867,-0.09624278489189475,-0.9043005832756086,-1.8247662483260398,False,c1,3,"This is a little tricky on the Parsoid end since Parsoid gets the PHP preprocessor to expand template source for us (which we then parse and process). So, Parsoid never sees the redirect that are embedded in templates (like {{cn}}). So, this will require us to instrument the PHP preprocessor to provide Parsoid with this information. Offhand, I cannot think of any efficient trick that will solve this.
So, I think approach (1) above where TemplateData adds redirection info and VE uses that might work for the common case where the redirect target is not a function of template args.",245448,13,,
-8.183816476646438,-0.6092829816436751,-6.314330561296739,9.47594914361523,12.406139383736544,0.6502863157278149,1.7001284175172557,3.1758411686430947,-0.1156192547477134,-0.836250206405059,3.201361007369322,0.855202967428176,-1.821255633714235,-0.5364520324960796,0.8305591037124103,-3.736693255959239,1.9410144200609383,-1.6675440919452484,False,c1,3,"Should a new bug for the Parsoid part be filed, so that the Parsoid team to do their part of this? This is a very big issues as some of the most common templates like the iconic {{cn}} are redirect and was asked about again at
http://en.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FFeedback&diff=575686867&oldid=575662727",245442,13,,
-7.381662255286985,-2.5005917651463747,-3.2964911119162053,-3.7463574320226094,-0.06864683572958263,-2.4225283423403248,2.019773032763279,1.599870286896318,-2.8159402309713366,-2.3752700521791628,-0.5366962177838219,-1.5128473760924672,-1.4395211131722323,-0.29819752938031274,-0.26740200267863123,2.306934309193026,-0.556177558780308,-1.8126542246329176,False,c1,3,"Both VE and TemplateData should address this in their own way. Both parties need to do something.
1) Resolve redirects in API interaction:
- TemplateData should have an option to resolve redirects in the given titles (like action=query). the mapping will be added similarly to how we normalise titles.
- Then the VisualEditor needs to use this map as the API response will put the templatedata for the target title, not the title queried. We do this already with normalised titles, so we can extend that to include redirects in that ""aliasing"" logic for normalised titles.
2) Parsoid giving TemplateData the transcluded page name instead of the wikitext invocation.
- Right now we sometimes get wikitext instead of a page name, or (in case of redirects) the sourced page name, not the one actually transcluded.
- If/when Parsoid is able to know what the wikitext expands too etc. (not a blind call to the PHP parser as it is essentially now) this will make that a lot easier and also solve generated transclusion target page names (e.g. {{ {{foo}} }} ).",245435,3,,
-0.9582752524862164,6.714916606031139,-7.4843636578809125,1.077292197942894,2.8930233565629475,-3.1977108607858575,-3.8657523161013367,-7.09946185065327,-3.1811621870453077,14.081151940008295,3.192657121381373,3.9514179689457842,-1.2936596300880114,2.6800689121392454,-1.8363925611471652,-4.8303629947579925,0.6269931667037653,1.8586251179174638,False,c1,3,"Note from bug 51791 fwiw: this issue is being discussed at
http://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/TemplateData#What_about_redirected_templates",245428,3,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51791 has been marked as a duplicate of this bug. ***,245420,3,,
-6.460739894423148,-4.73291766820914,3.6123776142340427,-8.206616475833302,6.654913273750427,-4.213654234913253,4.9460486569611835,-3.245427223232572,-2.193456982694066,-3.273237328061872,-1.645446908463783,-0.7355387458300573,-0.10650663590785214,-0.5449500640968553,-0.6965327826920291,2.4784703871407476,-1.9434811565991144,-0.9551297312554161,False,c1,3,"This bug has been fixed somewhere in the past week. The range is no longer (0,0) but (0,[document length]). The document no longer crashes and properly deletes all content.
However this uncovered another bug, namely that in Firefox deleting the selection now leaves the document completely empty (not even a placeholder
to start typing again). That is what change 86299 (https://gerrit.wikimedia.org/r/86299) addresses.
However this bug is fixed, though I don't know which commit fixed it.",244471,12,,
-3.150331544301221,-7.549615398546656,-5.42311009331705,-2.676419567127674,0.5813411238717912,-2.874686945076027,-3.3398946139188146,1.4295745048785182,0.539636342536232,-1.6085768750358924,-1.7570321959165214,-2.6711577096097314,-0.05072580604666532,-2.5470620517461837,-0.949917511629947,1.687364443164113,1.8979241944484364,-1.9356270283635426,False,c1,3,"When the document loads in Firefox (Firefox 24, Mac) ve.ce.Document#getNodeAndOffset gets called with offset=1 to show initial selection (range: 1,1).
When selecting all and pressing backspace, ve.ce.Document#getNodeAndOffset gets called with offset = -1.
It gets there from ve.ce.Surface#handleDelete, which has a rangeToRemove (from this.model.getSelection) of 0,0.
The #handleDelete method then sees the range is collapsed, and since backspace=true, it will get a relative range on the document from the (collapsed) 0,0 rangeToRemove to -1.",244461,12,,
4.040377903030814,-2.413807888615688,-1.476826404338873,0.33308885915649533,7.016623507706125,-5.311040675642811,4.428469386068475,-1.5876918798087076,1.7986112756171988,-3.6460944101984083,-1.689086634450348,-0.9189029763815899,3.0127087908178227,-3.110380003447343,-6.08017116179513,-1.9221661054349082,-0.2732260746183969,7.836286661646598,False,c1,3,This is still happening with Firefox 24 on Linux using the monobook skin (other combinations not tested),244456,11,,
20.110376129346115,-7.288100026089675,0.576090177190768,1.9992416915367723,-0.7321999459782393,-4.579433611163916,-4.361981526844039,-2.5295306546225405,0.6161642288862956,4.460306567017911,0.02716188648757578,-5.66011283832003,3.2857893969352165,3.7494495283263998,1.754699786517298,0.31670408738402056,2.700046131403338,-1.1051750134778713,False,c1,3,"**JohnCD67** wrote:
Occurs with Vector/Win7/FF23.0. It doesn't matter whether Ctr-A or Right-click/Select all is used, or whether ""Delete"" or ""Backspace"" is used to delete.",244451,6,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 52125 has been marked as a duplicate of this bug. ***,244447,4,,
-2.1682977354682262,-8.097428792406557,23.046396570405264,19.667325197892268,-10.212303465083208,0.6513193110662883,7.393630190674584,-10.420123493741706,0.5301666823471471,-12.211069862942974,5.228609090009083,-1.5781666144823165,-5.278358215739648,-3.7926905656215197,-13.722634142867676,1.4465144355862354,9.116493611576525,9.131472818511327,False,c1,3,Looking into it now.,244444,3,,
5.681606896208274,10.408098752575537,-2.0759239973085073,-6.91725214358346,8.693556229283839,2.3564228642025125,2.3651648410665693,-2.5301845398263234,-4.219770698137352,-3.7116248006280577,-7.743188970923354,0.48485519228430274,2.7768349062658872,-2.0798031250019484,0.08333576702926315,-3.052804305901129,2.5291366216287363,-2.161539130553444,False,c1,3,"Example from Bug 51169, which also has a screenshot.
https://en.wikipedia.org/w/index.php?title=List_of_American_Dad!_characters&curid=2082680&diff=564675517&oldid=564302759",244440,2,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51169 has been marked as a duplicate of this bug. ***,244433,2,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 50519 has been marked as a duplicate of this bug. ***,244426,2,,
9.89271305620953,2.306524507672881,4.624438842631138,0.6429476115774548,-3.153392276048381,-0.08065821148849217,-4.639378105044365,-4.573536569333353,3.5007539381293604,-1.999143407629544,1.963697909844617,-1.4566240875371914,-3.0197772324716765,0.44756985260193627,0.7928679536357381,0.9059155609866685,0.0628049004842953,-2.717200752098379,False,c1,3,"Yes.
In RL debug mode I got this:
--
[11:13:55.789] TypeError: node.getParent(...) is null @ https://bits.wikimedia.org/static-1.22wmf8/extensions/VisualEditor/modules/ve/ce/ve.ce.Surface.js:1265
It only happens in Firefox.",244417,1,,
-3.3214360047198634,0.20511815368304553,-0.009125556761729658,7.0802988488290115,14.911305736814604,13.2779748744769,-6.252620393052666,-8.462202333442434,-0.5156782864995897,1.1317610987898084,-5.227840239252851,-4.908624104625099,2.873057408984402,-4.272812227253875,-0.1733227966906674,1.418793225196583,-8.115585284105014,-9.402436524508017,False,c1,3,Do any JS errors appear in the console while you do this?,244410,1,,
16.783165369257354,3.9363518201096035,-3.949740893499444,2.6824648075839477,-0.39624033891118593,-3.106349871098809,-3.793723923512272,-3.4042889920345867,-0.7522277264443843,-1.3069932131369653,-1.184285611416854,0.9301222256761994,3.1401968772102515,-2.808164637016526,2.397329241994176,1.9235627817859668,0.3859980708371976,0.8436372675693291,True,c1,3,"(In reply to Krinkle from comment #8)
> (removed a couple duplicate see-alsos)
>
> Unless I misunderstood the bug, we haven't really made any progress on this
> since last year.
Yes, you have mis-understood comment 7:
(In reply to James Forrester from comment #7)
> (In reply to Elitre from comment #6)
> > What Chris described at comment#3 is still happening:
> > https://fr.wikipedia.org/w/index.
> > php?title=St%C3%A9phane_Bern&diff=100014868&oldid=98819232 .
>
> That's now in bug 62819, which we believe we have just fixed this week (to
> go out on Thursday). Closing this. The suggestion that there be two edit
> fields in the link inspector (one for anchor, the other for target) is
> tracked in bug 53973.
The remaining parts of this bug that aren't fixed are a duplicate of bug 53973.",244311,51,,
1.0737492148948649,-2.9903280101283247,-0.4958856609774911,-1.2685947891539797,-0.844587719540109,-2.736581269961434,-0.13923710085776442,1.5366930093208455,-0.13479077087318125,-0.9245762442145602,-0.7127620534579497,-2.1380134854112285,0.7126114407626121,1.3508995192956939,-1.0655978086919244,0.023134124933941624,1.772395516700646,1.979258411357924,True,c1,3,"(removed a couple duplicate see-alsos)
Unless I misunderstood the bug, we haven't really made any progress on this since last year.
(In reply to Maggie Dennis from comment #0)
> there are three things you could want to do:
>
> (1) change the link without changing the text (e.g. [[Mercury]] → [[Mercury
> (planet)|Mercury]])
> (2) change the text without changing the link (e.g. [[Mercury (element)]] →
> [[Mercury (element)|Mercury]])
> (3) change both (e.g. [[Mercury]] → [[Freddie Mercury]])
>
> At present it seems that the visual editor always assumes you want to do 1,
> and unless you delete the link completely there is no way of doing
> otherwise..., but for beginners I'd say that 3 should be the default. There
> needs to be some way to set the target of a link independently of what is
> displayed, and I'm not sure how best to do that but maybe an option on the
> link dialog called ""display as"" or something like that would be the way to
> go.
#2 and #3 are still not possible without deleting everything and re-creating a link. The only other way is to basically type the new label somewhere within the existing label, and then strip away the old characters. That's not something any user can be expected to do.
E.g. to change label from ""Foo"" to ""Bar"" of external link http://example.org:
1. Type ""Bar"" inside ""Foo""
- Foo
+ FoBaro
2. Manually remove ""Fo"" and ""o""
The main things lacking for this bug is a way to change the link label.
Or in other words, to select the contents of the label without its boundaries. Right now selecting ""Foo"" and typing over it removes the link...
Bug 37939 is also related (would make it easier to select it), but is not required.
Right now users would probably be forced into removing it and re-creating it, which hits bug 67086 / bug 67088.",244305,51,,
-5.125954142055659,4.714501798211845,-4.782575817394322,7.282240676208039,0.8923417912921909,-1.1025315461070928,-1.3614158314309073,-4.499489229086637,-2.52108921920256,-0.6517355569953236,-3.0117237761076914,2.736581593680844,1.1384254505395393,-1.0074505264298956,-0.4043887109452151,-0.9137501660584486,-3.117705422471704,-0.0893223420567959,True,c1,3,"(In reply to Elitre from comment #6)
> What Chris described at comment#3 is still happening:
> https://fr.wikipedia.org/w/index.
> php?title=St%C3%A9phane_Bern&diff=100014868&oldid=98819232 .
That's now in bug 62819, which we believe we have just fixed this week (to go out on Thursday). Closing this. The suggestion that there be two edit fields in the link inspector (one for anchor, the other for target) is tracked in bug 53973.",244299,37,,
23.591672978048877,-11.590196302996713,1.1831568067371325,2.1706378697223805,2.5749327614313646,-7.860906635643145,0.85741701920956,-6.620026675328021,2.3598193319965883,0.3059473932935388,5.136479244025675,-2.8264677091632833,3.6616563063494203,-2.121330875376735,-1.741529866177833,-0.12236463037230871,2.5221862900731153,4.386424890573698,True,c1,3,"What Chris described at comment#3 is still happening:
https://fr.wikipedia.org/w/index.php?title=St%C3%A9phane_Bern&diff=100014868&oldid=98819232 .",244293,30,,
-4.159639508935263,-3.5625306646431394,0.007733581952292123,-4.31244768801837,2.1372347588946123,-8.169290622403235,7.729323202698799,-3.6349807698320196,7.622320213649649,0.26207448609318096,7.4785195152713495,-2.877623660628915,3.8240500107185538,1.9687504220210175,-3.0418753081870173,-4.6641036183460045,0.38295123665166264,4.835201546274407,True,c1,3,"This is no longer true, since late July when editing of link anchors was made ""spanning""; closing.",244288,8,,
12.299555274817068,-3.207052876177583,-4.256193412821042,-4.176798663088215,-0.17773208470572577,-5.148223320965746,-3.7535599822196195,2.2849854589502097,-2.1974775888707665,-2.226721760252453,0.6244480039570661,-5.8652238634336475,0.9395715454485933,2.289777248804426,-2.3614192090363533,1.7291898968952493,2.8695427151760464,-1.0819936569443538,True,c1,3,"This is causing content corruption on the live wiki.
A user apparently trying to change a link from [[Blackpool Grand Theatre]] to [[Grand Theatre, Blackpool]] over two edits failed to do this:
1. ""[[Blackpool Grand Theatre]] and"" → ""[[Blackpool Grand Theatre|Blackpool Grand Theatre]] and""
2. ""[[Blackpool Grand Theatre|Blackpool Grand Theatre]]"" → ""G[[Blackpool Grand theater|rand Theater, Blackpool, ]]and""
https://en.wikipedia.org/w/index.php?title=Bernie_Nolan&diff=prev&oldid=564655203
https://en.wikipedia.org/w/index.php?title=Bernie_Nolan&diff=next&oldid=564655203
This should not be marked as an enhancement, changing links without mangling the text should be a core requirement of VE.",244283,2,,
3.060862962466471,-5.767427373196436,9.85706717063264,0.8845824905082278,-3.705398201249971,-7.764876003708228,2.2578203933204204,2.212672713782295,3.030635342867259,-4.30226292234982,4.749002232972235,-0.7060554913919397,1.6140790883009348,7.759991153879475,1.1102346284417082,-0.21234342642280835,0.40882519054295074,1.0540227980864203,True,c1,3,"It should be. However my testing showed that this was not reliable and sometimes resulted in odd wikicode, e.g. [[Ecuador|]][[Egypt|E]][[Egypt|gypt]] when changing ""Ecudor"" to ""Egypt"".
See https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox&diff=563097916&oldid=563090562",244278,2,,
-6.63075166942977,-4.9997811392750044,-2.303548619204412,0.243311606445749,0.011200572064099745,-0.8229262294028512,-1.5326851609687875,1.931302362687763,-3.4039400792726084,-4.103813156665078,-1.0636568511529028,-5.083469334960422,2.141023714842876,5.555110336429527,1.0375326155346447,0.14761079973643954,1.6659464012550238,1.6495924953726386,True,c1,3,"""and unless you delete the link completely there is no way of doing otherwise...,""
Isnt (2) and (3) possible by editing the text of the wikilink in the normal editor (i.e. not the link dialog), after selecting the link target?
I must admit I was dumbfounded for a few minutes when trying to do (2), until it occurred to me that I can edit the text in the page.
(3) is a bit harder, as the user must change the target from 'Mercury' to 'Freddie Mercury', then change the text to 'MFreddie Mercury', then remove the leading 'M'.",244273,2,,
-9.236817534444459,-4.377555126544388,0.07955435349376794,10.746419999551401,-3.1106424230909617,3.7368081747343957,-0.20041691896258307,-0.5059572630907208,-0.5533690433162176,2.6266205681830943,-1.6155769469199024,-1.458929631544041,-0.0754362918053939,2.469914333022939,3.1829232750568943,3.2559254272781857,0.7006812325889421,-0.5103335245261822,True,c1,3,"I'm guessing it would be possible for the display as thing to also have suggestions, e.g. in most cases on en.wp if a title has parentheses then you don't want to display what is in them as it is disambiguation. For example if you chose the link [[Mercury (planet)]] the software could say ""Do you want to display this as ""Mercury""?",244269,1,,
-10.471962018658866,-4.671616081487029,7.598151011997071,-0.16154739115260064,15.870584486918716,3.744702088581498,0.03592389329483403,-11.327021162547027,-1.6758592144289848,4.59362208927549,1.5142719258963315,-1.2673932315889669,1.781254642980591,-1.0135626667734376,-0.05063077796183757,-2.3825748753804867,1.6463236041080749,-1.7442795673446339,True,c1,3,I believe that this has now been fixed given the changes to how the CSS is cached.,242402,4,,
-10.843751154623929,-0.759681375078932,-1.3264047763596776,-4.269987462516493,3.2381152459548215,-1.2089893375645566,2.230649448575443,-1.343325221401948,2.514599268609765,-4.234038213024794,-1.6039369784159874,0.6126353100414494,-1.0369788321131508,-1.3320418112510517,-3.467809212351187,2.4185739445264454,-1.2889691689793605,2.7457668854062,True,c1,3,"As noted in the duplicate bug 50991, this issue is somewhat elusive but definitely occurring for some users. Given the impact when it does, increasing severity and importance.",242399,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,True,c1,3,*** Bug 50991 has been marked as a duplicate of this bug. ***,242395,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 53161 has been marked as a duplicate of this bug. ***,241992,7,,
-4.620518091940694,-0.6237128462879689,1.2993096613103297,4.925324565820093,3.463093681625752,2.979798153217331,-1.5460281214902842,0.5563321656082454,-3.7042541148259422,3.425784727189413,-1.1214826886112368,-3.814658624558713,2.9128018679112424,-2.683580924763917,-0.9952166098525674,3.4164398040519006,-1.2910836655895344,-1.4014760517466318,False,c1,3,I posted a fix which seems to work but requires some testing and review. Also testing in RTL seems to work.,241986,6,,
14.469008031845812,-1.0487048540677453,5.930910167833156,-0.09843098877755807,-4.07272528085082,0.911398133305676,-6.719683786685566,6.9044419771460355,-2.9381314075698626,4.006817120275352,0.382948303396891,1.8752502806319544,-0.9081981858050634,-1.0217900596622727,1.2195839476332608,1.85422861174343,-1.3105875123067154,-0.030045095647115883,False,c1,3,"(In reply to comment #2)
> This may be an issue with the way the icon appears in general, not just
> specifically RTL. It seems the transclusion icon pops up on the side of the
> page, assuming the position is always on the side -- instead of, perhaps,
> appearing where the template box is located regardless of alignment.
>
> I am not sure if this fix shouldn't be a deeper VE fix rather than the
> language-directionality specific fix.
Yes, I think a deeper fix might be appropriate - would you want to do that, or should I ask Rob?",241975,6,,
-12.528914546092897,-0.6566885360963841,-2.0050767142129136,-1.6978378251938775,10.7411887434099,1.0944153579280158,7.000367534478199,0.4714280524582307,0.09041326454888843,-3.2802835280150417,-1.9742528362308365,-0.4686607898910333,0.8593642909002641,-1.3106876770196214,1.1374344951428181,0.3201773787241313,2.6638557900144595,1.013715332533455,False,c1,3,"This may be an issue with the way the icon appears in general, not just specifically RTL. It seems the transclusion icon pops up on the side of the page, assuming the position is always on the side -- instead of, perhaps, appearing where the template box is located regardless of alignment.
I am not sure if this fix shouldn't be a deeper VE fix rather than the language-directionality specific fix.",241970,6,,
30.240930403549534,-8.562268690083638,-15.818205501576502,25.16718740919793,-4.3026377773412685,-7.3262838419669425,-3.1417591500510715,-4.213049172676461,-1.7397294335665192,-5.673290725725896,3.6532204691868633,7.698988334113937,9.637947159589135,-4.0694892740301905,4.0574175154290915,-7.173828695866911,2.5964939857702984,-0.6719150969194327,False,c1,3,confirmed on Arch linux with FF 22.,241964,0,,
13.606936578194341,-6.541596029545622,-5.5559017705725875,-1.7971551672034156,-0.12655169382534126,-2.1656339333651253,-1.7451243137533474,-0.7908144963331943,-1.3457933095448857,-2.1400902483838267,-0.8125744965958379,-0.7955651789744449,-0.6295836555088643,-0.7567917060381862,0.28594906380698637,2.018560987896813,-1.170338729553674,-1.599686929993276,False,c1,3,"(In reply to comment #1)
> Created attachment 12774 [details]
> API response
>
> To make it easier, after I restored your edit at
> https://zh.wikipedia.org/w/index.php?diff=27157124
> the content of
> https://zh.wikipedia.org/w/api.php?action=templatedata&titles=Template:
> X1&format=jsonfm
> was like in the attached file.
>
> What was your user language preference when you tested this?
>
> Does the problem happens on both of the following URLs?
> https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/
> VE?veaction=edit&uselang=zh
> https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/
> VE?veaction=edit&uselang=en
>
> For me the bug only happens in the second one, and I think this is the same
> as
> bug 50431.
The bug only happens in the second one.
I think the problem that I reported comes out because of the language conversion of Chinese Wikipedia.
The TemplateData only works on zh, but not any variant of Chinese (e.g. zh-hans, zh-hant, zh-tw, zh-cn, zh-hk, zh-sg, zh-mo). Should the data in zh be applied in those 7 variants, or otherwise, editors need to set the description for every variants which is time-wasting.
**Attached**: {F11388}",241034,0,,
-1.4025958823807647,1.8134466093372055,1.6950864895444742,1.2377183839926396,1.7847866664587322,4.402570927016097,-5.101283508524711,-0.6318513758821751,0.0537057952838923,-4.1359006675002075,0.9434602657466313,1.339215769824314,-0.17981881879789707,-0.12414320715628047,-0.35554861142521865,-1.4953344324175588,0.4616840798361789,-0.9925796328546586,False,c1,3,"Created attachment 12774
API response
To make it easier, after I restored your edit at
https://zh.wikipedia.org/w/index.php?diff=27157124
the content of
https://zh.wikipedia.org/w/api.php?action=templatedata&titles=Template:X1&format=jsonfm
was like in the attached file.
What was your user language preference when you tested this?
Does the problem happens on both of the following URLs?
https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/VE?veaction=edit&uselang=zh
https://zh.wikipedia.org/wiki/User:Waihorace/sandbox/VE?veaction=edit&uselang=en
For me the bug only happens in the second one, and I think this is the same as bug 50431.
**Attached**: {F11388}",241029,0,,
-11.909197056858481,8.083322923043006,-14.382751101438666,4.521666329478526,5.768102676009066,3.055084324719065,0.641990490066032,3.036293484714883,0.952404530913155,-5.514852364092849,1.41054589481634,-5.257863413647273,4.195207303988452,8.890951873343116,5.680571589002208,0.9540933617527689,1.4248506669885515,1.0554247491382287,False,c1,3,Confirmed the fix in production - the templates' contextual menu is displayed either on the far right of the screen or at the middle as for 'Cite web' template.,239068,70,,
-14.585866436981997,-0.1648971486108124,-3.165957535444325,3.9068674023648153,1.8922261401514895,5.247796120109623,0.322540971600791,-1.9087167211303253,5.7912054943223445,-1.8190623749169572,3.2959162321819866,-1.0176613479851113,-1.3770549173724325,-0.5608833757355909,-1.9393515984211072,-3.8258194614313683,-0.6971446480516487,0.7520545236780847,False,c1,3,"Sorry for having not responded on this ticket; we fixed this ages ago with the new contextual menu. There are still some issues with the context appearing off-screen if the template is taller than your screen and you're down-page of it, but that is covered by different bugs.",239065,68,,
5.925366941723796,-6.33243807471301,1.9136167615317472,4.034360992270775,-2.6764354800521524,3.6115442541186447,-0.4093368080694759,0.9552351276716564,0.6511417203034489,0.3373235169100264,-1.9720187139047174,-1.2644764200277332,0.9001007911327998,-3.088727489309866,0.7902325216960291,0.6741206398011625,1.0011610111872966,-2.1812338863630236,False,c1,3,"Screenshot of cs.wp Křivá Ves shows the wrong possition of edit button.
I agree. Look at https://cs.wikipedia.org/wiki/Křivá_Ves. If you want to edit the infobox, the key/edit button goes completly to right, where you might not notice it.
**Attached**: {F11331}",239061,10,,
-9.683877970658699,5.169275887417186,-3.435656205828656,1.4728219926258088,-0.9254137682251447,4.479708559282422,-3.482927341607806,-5.0429322585196585,-1.4091617280928639,-4.235615577100991,-0.4669179495740663,3.92959081828836,-2.7023990963696733,2.2367745873518654,1.3077296285061037,2.744197003428108,-0.36354263886184557,2.053479984924824,False,c1,3,"I mis-understood the bug as reported; my apologies. It is in fact entirely a duplicate of bug 49699. Marking as such.
*** This bug has been marked as a duplicate of bug 49699 ***",238984,0,,
-1.7491909414340228,-2.4229441474793507,-2.74412576272277,3.389025571064886,-0.16319296977478714,-3.0769375398587346,2.047849047785901,0.9348204104470068,0.8916578987793871,-2.680817956272058,1.5816008590148578,-0.9617035122179729,-0.6939810164551605,0.8701208943417666,0.014697159998452225,-0.30348500205874407,0.771651223337877,-0.21398684686284586,False,c1,3,"Isn't this just how FlaggedRevs (this is a different name for the same thing AFAIK) work? Edits by reviewers are only autoflagged if the previous revision was flagged as well.
Unless I'm misunderstanding something, the bug as described by the current summary (""VisualEditor: Edits made by users with +reviewer rights should not get flagged on pages with FlaggedRevs enabled"") would be a blocker to deployment on Wikipedia using FlaggedRevs for all articles, like the Polish Wikipedia. However it seemed to behave corrently in my testing there.",238976,0,,
-3.590675886444951,3.3721886946040946,-2.547128146538811,-4.798278939785844,2.5310807839268907,1.4584117137781334,4.752252722248613,1.4754793916171511,0.7708458352957495,1.3539959135550346,1.6438350412115301,-2.5497390220831924,0.4665603618979888,-2.2637938141424288,-5.813027124272886,1.6474367096492484,1.8895522936522318,7.891690478348687,False,c1,3,"Expanding on the above, when editing a PendingChanges article with actively pending changes using source code, admins/reviewers must either accept or revert the outstanding PCs before their own edit is saved. This is not happening under VisualEditor.",238967,0,,
-5.647513335124022,-12.781497771610464,11.243747466461112,2.489291418897386,5.029516088174033,4.1927164404362145,3.407494932144038,-3.8140183105196956,-3.824690500860985,-1.8200726940441183,-1.0745467521858778,-2.152775823722942,2.245684190476279,0.02993320270425337,-1.744267235688254,-2.952611772996455,-4.071418506842894,-2.761011858868758,False,c1,3,This is now INVALID because we don't select the node after insertion any more (should we?).,238865,8,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51863 has been marked as a duplicate of this bug. ***,238857,3,,
-9.959225581768571,-7.657020926389153,8.756208274364555,0.9592240674742705,-1.5100861524055986,3.206391328728749,0.7802983103917907,-1.0908359276325879,0.6188532590209641,3.7753828728653147,1.1953527953216796,0.5582411417942845,-1.7713692613702183,0.8092247237454389,-0.3769893540489071,-0.6047694305702991,1.7975055565533926,-1.6473666422909596,True,c1,3,"There are still some scenarios where nowiki wrapping will be applied to a longer string than required. I haven't tried to optimize it all, and if there are still issues, I can revisit it.",238268,2,,
-4.669110599025451,-6.2894949281300105,13.260666015148395,-15.145470670490454,8.705629869344854,-14.76550602245713,15.120695173311825,-1.730927098475345,-11.046374160856539,8.760670279628046,11.211302349654078,3.821308723777956,-4.967706796128818,4.709889703075427,-5.932802304368231,-1.902853874537477,-3.195044635108521,-0.29469942900024737,True,c1,3,This will likely be deployed later today.,238264,2,,
-0.8294855777264916,5.030185340282117,-5.079196989276189,2.33113501837593,-6.591655477557868,-5.492147372822462,6.827889839078564,13.45947372736347,17.761800032151978,1.1887165828063786,-0.24847264892003906,6.118917604159418,-4.153903944851635,1.1218395336336682,1.5763827023417516,1.1441702947855683,-4.819463433321377,-0.7527963052584004,True,c1,3,"Possibly interesting nowiki watch list to monitor nowiki application in live edits:
https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&offset=&limit=500&wpSearchFilter=550",238246,1,,
6.145530297058707,1.7300612760819263,-1.6681882871026126,4.796212021102265,-7.535050414608367,-4.509590497972113,-4.898699949909309,-1.5187641886415886,-1.9732485391806616,3.1587696079598953,1.1590685454841694,1.179155753241302,0.7513018570361987,-1.3023378431901966,0.2025567818278784,5.310856278714432,-1.0272070458041085,2.03289426644456,True,c1,3,"(In reply to comment #11)
> Oh I got it. We want to have -{ }- work, so we can't place
> -{
> }- back until all other -{ }- markups have been processed, but this also mean
> other text in nowiki misses the chance to be converted...
I guess -{ and }- in nowiki could be escaped before applying language conversion.",238240,1,,
12.821718180076973,-4.342070155416552,-0.25605610905207277,0.3571775090730931,-3.8572113177180283,-1.4606049090469515,-2.601272463836506,0.001795798937758275,-0.11750524268993856,0.5699618090302652,1.0414824309434703,-0.3516366568065079,-1.0873123934759024,0.0063244060836396,0.5264822838306142,0.594381511389245,-0.6910430997047039,-1.3688295977120895,True,c1,3,"(In reply to comment #10)
> (In reply to comment #8)
> > For us it would be helpful if we could separate those two aspects. If little
> > existing content relies on language conversion being disabled in nowiki, then
> > that might actually be possible.
>
> There shouldn't be much. It's the case just because in Parser.php,
>
> $text = $this->mStripState->unstripNoWiki( $text );
>
> is placed after
>
> $text = $this->getConverterLanguage()->convert( $text );
>
> but I'm not 100% sure this is just something accidental (or placed in this
> order delibrately).
Oh I got it. We want to have -{ }- work, so we can't place -{ }- back until all other -{ }- markups have been processed, but this also mean other text in nowiki misses the chance to be converted...",238233,1,,
-3.3951206614249556,-2.324329238931165,-0.6694441277655889,-0.7781495087258321,-3.0839729803805014,-4.899340808964389,-0.6038708317083863,-2.1330267143232846,1.3983102466093642,0.36576388445171926,-0.8749893053042475,1.2009301494580003,0.2878432953790244,0.8790925597490908,1.0476934679690424,0.5563814252957271,-1.4724838327995953,-0.5581239708366632,True,c1,3,"(In reply to comment #8)
> For us it would be helpful if we could separate those two aspects. If little
> existing content relies on language conversion being disabled in nowiki, then
> that might actually be possible.
There shouldn't be much. It's the case just because in Parser.php,
$text = $this->mStripState->unstripNoWiki( $text );
is placed after
$text = $this->getConverterLanguage()->convert( $text );
but I'm not 100% sure this is just something accidental (or placed in this order delibrately).",238223,1,,
-4.8695712561156705,-6.139721380950982,-0.5158194962249139,0.0905599465562279,-2.6819584783749333,-4.707345431366885,-1.7735654261358267,2.3273417388498423,2.8665394875987307,-1.3662613158614167,0.7969990628124309,-3.769090644833526,0.45898130420776884,2.5151869741652764,-1.4196219665370777,2.067119976267669,1.4551379168518326,-1.1973577054428555,True,c1,3,"Gabriel and I discussed the entity solution on IRC, and Gabriel made a good observation that fixing those in 'edit source' will become much harder compared to nowiki tags. So, entity-based escaping makes fixups harder using the source editor, but makes it easier with VE. With nowiki, it is the opposite. But, presumably the noneditability of nowiki sections in VE is temporary.
I'll tackle this with nowikis today by only changing how identified text blocks are escaped without trying to optimize placement itself (Ex:, in reality it is sufficient to only escape ""[["" or ""]]"" in [[Foo]], but that requires more global knowledge which will complicate this).
We'll try to wrap closely occurring wikitext chars in a single nowiki block. So, ""[[foo]]"" will be wrapped as [[foo]]. ""Closely occurring"" will be heuristic based, say within X chars.",238215,1,,
2.278741956428382,-2.9708548946101185,-0.5132992117866559,0.4854803231295737,-5.1349166906698205,-5.0931143928411995,-2.5050808252952965,1.4961864247955847,2.5839787727892753,1.619312332648228,1.334378393593362,1.9300558933825451,-0.7635283307531946,-0.8962249641224553,-0.6796876429460079,0.7404048029150947,-0.7103654606847253,0.28864565916039897,True,c1,3,"(In reply to comment #6)
> Actually, why not use entities for escaping? That will eliminate nowikis,
> make
> them editable, and display as text.
>
> [[Foo]] ==> [[Foo]]
>
> and the like. Am I missing something that makes this problematic?
Numeric entities are very hard for users to decipher. While unwanted nowiki tags can simply be removed, fixing up unwanted entity escapes is much more work.
(In reply to comment #7)
> (In reply to comment #5)
> > Re language conversion:
> > How often is nowiki used to suppress language conversion? Could -{ }- or some
> > other syntax be used instead?
>
> It's more like some side effect...
For us it would be helpful if we could separate those two aspects. If little existing content relies on language conversion being disabled in nowiki, then that might actually be possible.",238209,1,,
3.5072259712675535,12.045474251634115,0.4575450689501359,2.852686742652171,-6.939262829902001,-0.444320357425406,0.32017118967934977,-2.6125602502549734,-2.094092946000528,0.3668166521807743,-0.7318938305688936,2.1729060618203464,3.3146857845151683,-3.6367826371442726,2.8001739043638763,2.371836005620552,-1.4630818156984415,-1.9938991756454316,True,c1,3,"(In reply to comment #5)
> Re language conversion:
> How often is nowiki used to suppress language conversion? Could -{ }- or some
> other syntax be used instead?
It's more like some side effect...",238202,1,,
-3.5604849921417303,-7.244121197908768,5.65399387073802,-6.761473713245546,-4.278900432321238,-3.272576973619767,-3.4950501643081218,2.765792244690224,-1.577303061890551,0.22302002040520907,-0.29884596728759005,-1.6514325166236343,-0.8990068376365161,-0.7219773292489627,-5.787245644750719,2.146484808813067,-0.64121111611077,-2.603179460129335,True,c1,3,"Actually, why not use entities for escaping? That will eliminate nowikis, make them editable, and display as text.
[[Foo]] ==> [[Foo]]
and the like. Am I missing something that makes this problematic?",238198,1,,
-7.34913664083752,-2.339876465346652,3.725823987843576,-2.793656180539992,-1.2786746484783365,-4.7061762034882175,7.016699790564248,3.4480081640719886,2.136857135724701,0.05014289665627025,1.0761365015506053,1.3828021797738028,-1.8292386749306098,-0.4226915106376037,-1.6834078000682886,1.4987540398555723,-1.980245589532194,-0.10507696019927115,True,c1,3,"Maybe we could still use a single wrapper but exclude unsuspicious leading / trailing text from the nowiki block. I agree with Subbu that escaping each run of dangerous characters individually would often result in too much nowiki noise.
Re language conversion:
How often is nowiki used to suppress language conversion? Could -{ }- or some other syntax be used instead?",238195,1,,
-1.4358078186201366,-3.4520118385350873,0.2523844103089319,0.630524454264858,1.1663772899257783,1.9062987532973459,-1.7772254326744612,1.480847773449764,3.3059452278935852,-2.8565141408436636,-1.011165390428058,-1.6634891866254828,-0.5889662340017472,-0.550562698947651,-1.9380908350439103,0.5327635040283045,1.0441210358985655,-1.1638268894052861,True,c1,3,"It should be noted, that at present VE aggressively grabs normal text on either side of the offending elements as well. For example, using VE to enter:
- I am the very model of a modern [[Major-General]], I've information vegetable, animal, and mineral, I know the kings of England, and I quote the fights historical
Becomes
- I am the very model of a modern [[Major-General]], I've information vegetable, animal, and mineral, I know the kings of England, and I quote the fights historical
Even though the plain text at either end of the wikilink could reasonably be ignored without increasing the number of nowikis. Since VE can not currently handle nowiki elements, that also means that the entire sentence becomes uneditable in VE after saving.",238191,0,,
-7.383377271155011,-9.655679773226762,-2.9262736707702084,-2.3977287703573733,2.0282176015595077,-7.743585456534014,5.286474124631116,5.588686711865946,0.8726983152075718,3.3397760106843757,1.557866819049711,0.43024704918845913,-1.9004958610531404,0.17943769562773149,-2.0931221884728517,1.2336081007349118,-1.2958357841417676,0.27004330398627996,True,c1,3,"Actually, another way is to use the existing algorithm to detect contexts that would have been wrapped in .. and apply nowiki-escaping to all possible wikitext chars in there (which is safe, but excessive). This will not complicate the algorithm anymore, but will also introduce more nowiki tags than strictly necessary.",238187,0,,
-7.486508516445207,-8.749902206558119,2.3603217369666174,4.479028103315864,-11.123684381654648,3.74764782092457,1.1486746103141954,0.08403738628281898,4.339787166884676,-4.037146108762952,1.6825824853085631,-2.2476612146921813,0.5273048732610803,1.9931719333164517,-3.6472378210931606,-2.3654483322033832,0.3815746788372463,-2.3690645437326454,True,c1,3,"I forgot whether I pointed this out or not: applying on ""normal"" text disabled language conversion on it too; we may want to wikitext meta characters only.",238182,0,,
-7.7873097974877,-6.3993831257146745,-0.15779028869306932,0.6472159572088358,-2.5591591359642827,-1.891967903387961,3.7668467153457694,-0.34991634510897074,-1.2628007393984655,-1.384518617146469,-0.08545483091986439,-0.2708658862559217,-1.1571181059169346,-1.0206738455965099,-0.649713516194125,0.9418286299520018,-2.737840358000138,-2.3633847694331127,True,c1,3,"Let us discuss more on irc monday, but the general problem of escaping minimal contexts can complicate the algorithm. That said, we could implement some special cases maybe.
Also, a lot of nowiki-tags (as in this example) looks ugly to me (personally), and could potentially induce greater grumbling among editors. So, my suggestion is to minimize incidences of nowiki contexts via VE (however you do it) first, and then implement a version of this proposal in Parsoid after that.
Yet another (not fully thought out) alternative is to convert wikitext chars into HTML entities which eliminates nowikis altogether. We currently use this entity-based solution when we have to escape pipes in url/ext. links in template arg contexts and can just use that more broadly.",238177,0,,
3.2288119440080134,7.843354128176262,-4.229426899347946,1.6588173201667402,-4.868665863614867,-5.6635103403591485,-1.058114295811622,0.9731879018096347,-5.554688405699252,-0.01060505213310492,0.7878993122477109,2.184951303618192,3.0727573450409844,-2.3364744897910064,-0.9221300320658716,-0.2079402951859164,-3.1151929815234403,0.5631424626870833,False,c1,3,"(In reply to comment #21)
> It's resolved technically,
Closing this one then,
> but we want to write proper documentation and
> tests
> for the fix. Assigning to myself.
and split this to bug 54364, to clarify status.",238010,11,,
6.718084450381145,2.0187544962976585,-2.246637768431162,0.8487588809348221,17.544898819544102,3.615144138980334,-6.059188097048242,0.5072327719378895,-4.0562492912262815,-2.5053094137858083,-2.3717118563621553,-6.069237743510825,4.884680632264371,-4.634048684304344,-2.395759342073209,-2.4929376480315857,-4.3642323800031,-7.317817723637637,False,c1,3,"What's the progress on this, Amir?",238005,5,,
-9.582910966047821,-6.487755520843764,8.487383937968847,8.136002751169483,-7.76256868874381,7.992836672642053,-4.0775747383642695,-0.6352744869655867,2.82999475070294,-2.5232266078600474,0.6219247645016752,-0.7859329584195196,1.5768290393431341,-3.7527168889504114,-2.6052680878606242,4.727399979954699,2.3109171806082265,0.5859113531900579,False,c1,3,"It's resolved technically, but we want to write proper documentation and tests for the fix. Assigning to myself.",237998,2,,
-13.236061694077076,-7.989685019107552,2.248541449842934,-4.763278424276654,4.910161710061086,-3.0713453249164697,4.3978577463542425,-2.0294461298186484,0.13792145159590508,0.05388282212686235,1.748731449761924,0.6308220462845666,1.2377578651283825,-2.586786948840248,-1.163121919639816,-0.9260616393872101,-5.040192698786554,-1.478364899469889,False,c1,3,"Why is this still open?
as far as i can see, the patch solved the issue. is there any report about any more problems here?
is anyone expected to do anything more regarding this issue?
if it's not closed now, is there any chance of this getting closed ever?
peace.",237992,2,,
-8.813915056099406,-3.1210247908962288,-1.2262781005940018,-2.378319937972474,2.5701280194963427,-1.498683185544703,-1.4940473931927887,-1.284885533703907,-1.4610521300357808,-3.5360181193201394,-1.3436482473875162,-5.46406772014269,2.8659909313834833,0.985597758577071,-2.2443603463784867,0.3894208406105064,0.0689860789898388,-0.8764122840611468,False,c1,3,"What about using .eachAsync (https://git.wikimedia.org/blob/mediawiki%2Fcore.git/HEAD/resources%2Fjquery%2Fjquery.async.js) instead of the .each loop over $( '*[lang], [style], [class]' ) ? Perhaps this is not the solution for this bug, but for bug 49935, but I'm not going to read through all those comments, and I think the .eachAsync is worth a try.",237987,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51070 has been marked as a duplicate of this bug. ***,237980,1,,
-12.174780384667116,2.5641450073417893,0.18342827528418182,3.697127122490974,2.105358807269223,3.6472679437948905,5.201032880145917,-1.9994593081765206,-1.0541740717025812,2.614904258438729,-0.7434468393676021,1.48014147847955,-1.536790150120631,-0.06432224061273861,0.896559827523363,1.2740392491935535,2.484662595756308,0.041067205238693116,False,c1,3,"The above patch makes the webfonts code about 4x faster in my testing. While it is an improvement, it does not completely remove the problem. To go further we need to reconsider the logic instead of just optimizing the current code.
This patch is already on beta labs, can be tested for example in http://en.wikipedia.beta.wmflabs.org/wiki/Barack_Obama and is planned for deployment around 1800 UTC today.",237974,1,,
-4.640441206830002,-3.797464306752584,-4.382992014234718,-5.735383045038615,-2.124502652651251,-6.1488859083912235,1.298684558686018,-1.2661104333701885,0.9759068584142052,-0.0734766363857764,2.286461527716205,-2.2312652284645385,1.9434544480254585,0.1599727055125706,-0.8996102827485719,0.5021013183160732,-0.5585804043145205,2.691626409188394,False,c1,3,"(In reply to comment #9)
> SpeedyGonsales: This bug report is specifically and only about ""Loading a
> page
> which requires many fonts causes high CPU load"". If you want to generally
> talk
> about ""preferences for new things"" or what MediaWiki should be, please do
> that
> on some forum or Village Pump. Thanks for your understanding.
it is unfortunate that ""some forum or village pump"" where the people responsible for the content of wikimedia deployment are actually listening, does not exist.
there is another bug on bugzilla ( bug 46306 ), requesting/demanding a kill switch for ULS. this bug was closed with ""resolved/wontfix"".
yet another open bug ( bug 51070 ) is requesting/demanding to disable ULS on enwiki. this one was not closed with ""wontfix"", but could have been just as well.
so complaining about these demands/requests spilling into other bug reports is somewhat unfair, IMO.
peace.",237956,1,,
5.978610221414053,11.979957795563973,-7.676065355092636,2.291634648289259,3.273670129697292,2.7258353536312754,7.431309019076194,2.058200554924009,-2.648511117018848,-1.044979117791121,-0.9823173376980194,0.9958431269255525,-0.4714001869327138,-0.9627075030460948,-2.209258428778915,-3.204358970690166,3.8618026482886947,2.0640494617279495,False,c1,3,"Just a note that the Language Engineering team responsible for ULS will be holding an office hour later today, at 17:00 UTC on
#wikimedia-office (on Freenode): http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg69718.html",237947,1,,
20.25776006468778,10.15756881393289,1.5520645648902116,9.537915231102742,-3.7063526945666956,-7.112145961657829,12.37680046162304,-4.101651187606659,-0.8447838049089893,-4.3923747438954654,2.8302905840272032,1.365069675700183,7.255302520539662,-7.306388883170645,5.315401973970653,2.040386948430127,0.13227995373488707,-2.348359592748136,False,c1,3,Also reported at pl.wp: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Ostrze.C5.BCenie:_Skrypt_nie_odpowiada,237939,1,,
-9.560201975846367,-2.2622564840034176,-0.44230723349228285,-1.4755336826895746,-2.612151819049653,0.41977288445431604,0.4522708190713818,0.2687041362529243,4.780291152796351,-1.7961030815736447,0.9778701566040624,0.06572120746864751,0.9484379135372794,-0.9028566447269673,0.6913662773890561,1.313119345025159,-1.7389262230488747,-1.5922024889852027,False,c1,3,"Eduard: I can understand frustration, but no need for rhetorical questions, plus ""I wasn't heard in the right place, so I tried again in some other, wrong place"" is not a good argument.
Tools (like bugtrackers, mailing lists, Gerrit) serve purposes and have dedicated audiences. Bugzilla is a technical bugtracker for bug reports that refer to specific codebases. It's not for meta-level discussions on development policies, plus from experience in other open source projects I can assure you that the more comments unrelated to a bug there are in bug reports, the more devs will (understandably) also start ignoring bugmail and bug reports. I assume that's not wanted by anybody, and that's why I explained how to avoid that.",237933,1,,
-3.1011930998042803,-1.427057451117964,-1.0105809106852026,3.2360345897426033,-3.5446310103903222,3.910102243935807,-7.164179308460916e-05,-1.8745177213680728,4.600838241794702,1.0516671178330323,-1.1374800841771369,1.0050119816080825,0.08694760719587613,-0.13359945866244827,1.0140754071129865,-0.21965866997814798,2.5385215269278105,-2.4320401382932415,False,c1,3,"Since one is ignored ""on some forum or Village Pump"" (*) one tries other ways to voice one's opinion. Is it surprising that people then try it on Bugzilla where one has at least slight chances a dev will peek at one's message an comment on them?
* e.g. http://www.mediawiki.org/wiki/Thread:Talk:Universal_Language_Selector/Disabling_ULS or http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#.22Opt_out.22_of_VE_needed_under_preferences",237927,1,,
-1.1657611512448582,3.6269596937780832,-1.8641662288027105,4.064521484819926,-1.0871293572599878,-0.5650532014365091,0.7593902143900078,1.5484597237947666,0.6896231360850864,2.276930141334116,-0.1295327590705755,-2.5791581646935966,2.993603344546881,-0.7319744305060648,1.8907868729951103,-0.4780591747343532,-1.586523389034232,0.16829829888783188,False,c1,3,"(In reply to comment #8)
SpeedyGonsales: This bug report is specifically and only about ""Loading a page which requires many fonts causes high CPU load"". If you want to generally talk about ""preferences for new things"" or what MediaWiki should be, please do that on some forum or Village Pump. Thanks for your understanding.",237921,1,,
-0.19758663935568777,-4.081217286143254,-2.0897083903004274,-1.4780008076048858,-3.624539099046693,-2.6012494704487708,-4.351416395099703,3.843252651764934,3.546306761715048,2.505781020764574,-0.2602555828459088,-1.8218621012280196,0.38621521615999566,3.34191554580008,1.4353470706809714,1.0231680028237613,0.6370901728204279,0.34930542761513017,False,c1,3,"If you ask me having ""disable switch"" (""kill switch"") in user preferences is a
must for almost any new things in MediaWiki UI.
If we are unable to alter closed OS (e.g. Windows or Mac) but are able to alter
open source one (Linux), MediaWiki should be smart and offer ""disable switches""
for new things. ULS is a good idea, but the same way I like to have ""kill
switch"" for VisualEditor :) (""Remove VisualEditor from the user interface"" in Gadgets), I agree there should be one for ULS, period.",237915,1,,
-3.8544995206440493,-3.1586999198868746,-3.8132632858445668,-2.8288803068183253,-2.8496273242604317,-1.8861292933715799,0.2687419128443356,1.0952505191289874,2.1686911874522945,-1.5270374024128053,1.4747909124599845,0.8488510619077827,-0.842997084519725,-1.402172347367439,-0.0913087917967097,0.6766319391515574,0.002002494904689789,1.3534542358227069,False,c1,3,"(In reply to comment #5)
> ULS contains quite a lot of new JavaScript and CSS code, so it is reasonable
> to
> expect that a close scrutiny of the code will reveal some measure of
> duplicate
> work and various other performance problems. It's good that you've dug into
> the
> code and pinpointed some specific problems, but please be less adversarial.
> Measuring and optimizing client-side performance is hard enough to do when
> you
> aren't under attack; calling a developer's code ""asinine"" or ""disgusting"" is
> not likely to make it any easier.
you are correct that my style is/was a bit abrasive, and for this i apologize. however, the ULS team demonstrated pretty bad behavior of its own: please review the way Siebard responded on bug 49935 .
in addition, turning it on on many wikis before cleaning the very serious performance issues (and causing browsers to freeze _is_ very serious issue), and then arguing that this thing should not have a disable switch in user preference is just wrong.
peace.",237910,1,,
-13.181651709903917,-4.346871293038301,-5.137750625635576,-2.782147508886112,-0.7994498933607774,0.11861019785142624,2.903739954583111,1.238519618520041,1.1462771279761885,-1.8337140078183176,-1.0917512893964072,-1.5787380642459663,-0.7469737694639877,-0.028701749845567726,0.6969157516273157,0.5112403632599318,0.8011405821450737,-1.5161436024452584,False,c1,3,"i think you missed the main point: when we call ""load"" with a font family such that this.getCSS() returns false (e.g. ""sans-serif"" on my browser), we do not cache the result. calling getCSS() is orders of magnitude more expensive than the search, regardless of whether the search is done the right way (through hash) or the wrong way (through $.inArray).
as to profiling: the real test is to have ~20 entries in the font table (like in [[en:Japan]]), and then measure how long does it take to look for a font _which is not in the list_, which is what happens today, thanks to the problem mentioned above. you'll see that the search takes significantly longer than it should.
still, the main problem is not the inefficient search, but rather calling getCSS thousands (or tens of thousands - depends on the page content) of times instead of once per each font family present on the page.
as to why we call ""load"" so many times: easy. set a breakpoint, and follow the call stack upward until you'll find the call that's inside an .each() loop.
peace.",237904,1,,
-3.5478244544589983,-0.49217700592288693,-2.23766351213552,-0.9190189391451877,-1.3851849062771722,0.3117990669513304,0.8392251320263657,1.1920686840984263,3.5028635048158367,-0.009985317105276614,-0.026819637362247573,-0.7617921485541457,0.7287294784360516,1.8829094905472263,0.46300327949241593,-1.0025485470769806,0.8288608558581376,0.33951006945618767,False,c1,3,"(In reply to comment #1)
> clearly, the right thing to do here is to collect all the different CSS bits
> and pieces you want to inject, and call injectCSS() exactly once.
I've only noted a single repaint in Chrome Dev Tools on https://en.wikipedia.org/wiki/Tower_of_babel, and I'm not sure yet if it's attributable to ULS. But any form of DOM access is expensive, so the recommendation above is entirely sound.
> the function ""load"" is also asinine, and can cause a high load:
>
> it has two problems: one of them is using $.inArray() to test whether this
> fontface was already loaded: this means linear search on the array every
> single time
Hash tables lookups are worse than linear searches for arrays of this size due to the cost of computing the hash and the relatively poorer locality. (In fact, modern JS engines don't even implement property lookups as hash tables, but I figure that was what you had in mind when you recommended hasOwnProperty instead of $.inArray).
https://en.wikipedia.org/wiki/Tower_of_babel has four fontFamilies: ""Amiri"", ""Akkadian"", ""AbyssinicaSIL"", and ""CharisSIL"". I used this to profile object vs. array lookup:
> var myArray = [""Amiri"", ""Akkadian"", ""AbyssinicaSIL"", ""CharisSIL""];
> console.time('$.inArray'); for(var i = 0; i < 10000; i++) $.inArray('abc', myArray); console.timeEnd('$.inArray');
$.inArray: 18.029ms
> var myObj = {""Amiri"": null, ""Akkadian"": null, ""AbyssinicaSIL"": null, ""CharisSIL"": null};
> console.time('hasOwnProperty'); for(var i = 0; i < 10000; i++) myObj.hasOwnProperty('abc'); console.timeEnd('hasOwnProperty');
hasOwnProperty: 13.161ms
The difference per call works out to just under half of one millionth of a second, certainly not enough to warrant calling either approach 'asinine'. I am running a recent build of Chromium, but I'd wager the difference even for older browsers would not cross the threshold of significance.
It is a bit bizarre that load() has to be called 877 times on that page, though. That should be investigated.
ULS contains quite a lot of new JavaScript and CSS code, so it is reasonable to expect that a close scrutiny of the code will reveal some measure of duplicate work and various other performance problems. It's good that you've dug into the code and pinpointed some specific problems, but please be less adversarial. Measuring and optimizing client-side performance is hard enough to do when you aren't under attack; calling a developer's code ""asinine"" or ""disgusting"" is not likely to make it any easier.",237899,1,,
2.3674813656501943,-9.71251699620764,9.007337537858378,-4.364828966579184,-0.997595351400399,3.832009482973117,-1.5636155368446918,-5.932457900592353,3.4402135947732644,5.771746003631174,-0.7752437481602454,-0.6755735981863582,0.26039690381564906,1.5151599667996971,0.8599119158341617,-0.3125181105011907,-2.3821125945264616,-0.5373655091629224,False,c1,3,"I've requested ULS be disabled, this has taken too long, it's annoying ppl without reason.
https://bugzilla.wikimedia.org/show_bug.cgi?id=51070",237892,1,,
-0.1603019164225037,-4.25230764761668,-0.3428832854991688,-4.897591619471864,8.207761992038176,-3.808331233844127,4.085789732453609,-4.877385716719109,-1.8981789625638639,-0.783574803276553,2.4921394946389195,-2.3103741339900763,2.664029828617487,-2.061740463764545,-0.8106053242871101,-2.693382902206816,-1.1589540655930841,-4.067457814719195,False,c1,3,"Why was this set back to UNCONFIRMED? Lots of people have experienced this, and kipod has even identified the fix.",237886,1,,
-9.960925594992984,-11.112365580524473,-0.33773261909650953,-6.336827614735817,-6.56466998360983,-7.93415455656861,-1.239341316938587,2.3833068514933973,4.324208430261839,-1.2325331278831664,-0.758817033174068,-2.8730832694954747,-0.9087712793127556,1.3212684456606898,-0.09731053743335005,1.647093326131282,-0.6948011096843191,-1.3118173916411568,False,c1,3,"P.S: i used ""abnormal"" to signify that getCSS() returnd false, when called with this font family and variant ""normal"". i do not think this is a good name - maybe ""empty"" of ""builtin"" or something similar will be better, as long as one can be confident it's not a valid fontFamily name. it has to eveluate as boolean true, though, so you can;t use false or empty string.
alternatively, false can work, as long as you modify the first line to
if ( this.fonts.hasOwnProperty( fontFamily ) )
so the thing becomes
load: function( fontFamily ) {
if ( this.fonts.hasOwnProperty( fontFamily ) )
return this.fonts[fontFamily];
var styleString = this.getCSS( fontFamily, 'normal' );
if ( styleString ) {
injectCSS( styleString );
return this.fonts[fontFamily] = true;
}
return this.fonts[fontFamily] = false;
}
(for brevity, assign and return on one line - don't do it in real life).
peace.",237879,0,,
-11.335845464598442,-8.15812898244769,-2.806582568350924,-5.774742939831469,-2.1800491707288856,-4.77279120322577,-0.4072289255523156,1.5224439321453094,3.425828235016727,-0.7529726122144784,-0.9061780677356013,-3.3727616940989336,1.5724429805403934,1.5620552800049199,0.23264300290518491,-0.6149168570288279,-0.47984558844252817,-1.3449718843375775,False,c1,3,"the function ""load"" is also asinine, and can cause a high load:
it has two problems: one of them is using $.inArray() to test whether this fontface was already loaded: this means linear search on the array every single time (that is, for every single html element with either ""lang"", ""style"" or ""class"" attributes on the page!), and for pages with large number of elements, this can be significant. whats more, there is no reason not to add the font family to the list even when it's not found, to save us some work with future elements with same font family.
even worse, when getCSS() returns ""false"" (which it does for 99% of the elemnts, e.g. when fontFamily is sans-serif), we don't mark this font family as ""tested"", so when we find the next element with sans-serif, we do all this work again.
from performance POV, this is atrocious.
here is a better version of load() - 100% untested.
load: function( fontFamily ) {
if ( this.fonts[fontFamily] )
return this.fonts[fontFamily] != ""abnormal"";
// does the font have ""normal"" face?
var styleString = this.getCSS( fontFamily, 'normal' );
if ( styleString ) {
injectCSS( styleString );
this.fonts[fontFamily] = true;
return true;
}
// Font does not have ""normal"" face.
this.fonts[fontFamily] = ""abnormal"";
return false;
}
note that ""this.fonts"" here is an object rather than an array (to save the linear searches), so it should be initialized to {} rather than [].
peace.",237871,0,,
-10.665395933165957,0.708547740798446,-5.19395417077525,10.350499682651998,5.97818835216585,-6.167026584778244,-3.3746740658601126,13.448546498740319,8.102488279166682,-0.5472242982744362,2.3931640801894347,2.9711806160875485,-6.357893192372011,3.2000200492272155,-3.466088939514108,5.698494621355816,1.5579480426950425,6.558592904677754,False,c1,3,Fixed and will be going out in a few minutes.,237287,2,,
-6.08780777132871,-3.3707766870591893,3.7557361355978642,4.762526048292843,-5.670864548000278,5.23028242815252,1.3614931761028863,-0.6467025103254299,-0.5631402886182637,-0.34186940810550137,-0.5244172890308632,1.9334115722904919,-0.5458946646468525,2.0487584343183993,0.05825733190773619,-0.8874502932390773,2.1574551615828277,2.405343549280986,False,c1,3,"Though I knew that the SpamBlacklist has logic in place for returning multiple urls (bug 30332, Ia951d5795c5cedb) it didn't seem to work.
Apparently it does work now. I can't consistently reproduce it only giving one. I'll presume it was an error on my part or an edge case in the regex SpamBlacklist is using and complex wikitext as input.
I've amended the patch set to display multiple urls separated by comma if there is more than one.",237280,2,,
-2.4914001138555935,-0.12847582581688144,-0.1271617378607437,-5.682365102201115,1.1353051594441723,0.7589149557814885,-0.3354576511089,0.40135142156525727,-0.49570314824404943,-1.665524188732645,-1.4504572479521425,-3.200948916849673,0.9922103580386223,3.4273487771361273,0.3895285720601098,0.31569840777738056,0.49347056817836776,0.2871609763307328,False,c1,3,"So we get the matched url from the API. Ideally we'd get a usable message as well.
Given the following sample (and latest mediawiki/core and SpamBlacklist configured with [[m:Spam_blacklist]])
* [http://cl.ly/foo/?bar=%22%3Equ%3Cb%3Eu%3C%2Fb%3Ex%3Ca%20href%3D%22 d]
* [http://fidosoft.de fidosoft]
index.php?action=submit gives the following:
> The text you wanted to save was blocked by the spam filter. This is probably caused by a link to a blacklisted external site.
> The following text is what triggered our spam filter: http://fidosoft.de and http://cl.ly
These are constructed in EditPage::spamPageWithContent by the ""spamprotectiontext"" and ""spamprotectionmatch"" messages respectively, which are actually in mediawiki core. The latter message takes $1 as parameter and EditPage.php sets that to the result of Language::listToText( Array ).
The API gives:
""edit"": {
""spamblacklist"": ""http://cl.ly"",
""result"": ""Failure""
}
For some reason it isn't getting the second url? The SpamBlacklist API hook looks like it is doing `implode( '|', Array )` but aside from an array being nicer than a pipe-separated list, we're not getting either. Only the first url is returned.
So either:
1) SpamBlacklist needs to provide a processed message
or:
* SpamBlacklist needs to provide both urls, not just the first (I tested latest master, SpamBlacklist@3390081e4c6). Though this bug should be fixed either way, if we don't get a processed message, needing both is a blocker.
* We'll load these 2 core messages as part of ve.init.mw.ViewPageTarget
* We'll need an equivalent of Language::listToText in core mediawiki.language.js (though I suppose join(', ') could do meanwhile).",237270,2,,
-1.970643044498571,-0.4758945498818772,-6.659805274102061,-3.3549940843719313,-0.8844314109428097,0.619930760740889,-1.9690361668121366,1.0728725410760074,-0.8595308161249837,-4.327100942213526,-0.6276092261341006,-3.6131784326472953,0.24509761453909773,0.1286397825753609,-1.291595812014111,-0.0893034746249759,2.1517592728426527,-3.1736040685370894,False,c1,3,"**joedecker** wrote:
Sounds like y'all have screen shots, but for those of us playing the home game, when I press ""Save Page"" on a blacklist-blocked edit, that window (with the edit summary, etc.) stays up, and ""Error: Unknown error"" appears below the edit summary box, to the left of and slightly higher than the Review your edits/Save page buttons--the latter inactive.
MacOSX/Chrome 28.0.1500.71, tested with an examiner.com URL at [[Chad Griffin]] with an incognito window/logged out.",237261,2,,
3.1904749996702098,-0.9397847655989366,-0.6316688418568619,-5.779135201997872,0.5288772366965251,2.376894315252432,-0.2361350452676909,-0.22843007497970702,-2.4412814544937085,-4.729876183395319,-1.7634225510181443,0.20855224529784167,-0.3832685646092209,-0.6566121830842714,-0.15283061780679175,0.29852151601905375,-0.3293508889737191,-2.022083777137923,False,c1,3,"Created attachment 12821
Developer console dump
A very helpful user in #wikipedia-en-help gave me this screenshot of what we get back from the API when TitleBlacklist rejects an edit.
**Attached**: {F11276}",237253,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51139 has been marked as a duplicate of this bug. ***,237243,1,,
-7.9511218512660875,-3.0008411626824856,5.881240320727702,-2.410923516712314,6.181610334569875,-0.8616300380765125,0.42519080415021193,-2.6857561541553014,2.2991161965149347,-2.8715145138258644,-4.622106578410083,3.1317815060972327,-2.8754789186445446,3.2583249110830828,2.103703468023772,2.9854007518429952,-6.580480660981913,-1.339709430333555,False,c1,3,"As far as I can tell, these issues have all been fixed now. However, there's bug 72929 which I've opened for a new issue that's developed in the past few weeks.",237062,70,,
-6.1569211977881695,-3.380419576024842,-3.8637795231806447,-3.5943448635694875,2.7530741740061035,0.08807457935778373,-0.3252316908478079,0.5171434810616417,-1.4942203747032134,-6.826841091959649,-1.5156799653779083,-2.289660291804044,0.3579060772395932,2.059831679016618,1.336764428252593,2.313413148202651,0.09261695083179147,0.06028490227830785,False,c1,3,"I have issues with this locally as well (Iceweasel/Firefox 24.4.0 with VE 3b3a66763ade397b857e35efe8990ac217e5d54c , in debug mode.
In my case, when I try correct the word, it does change in that spot (fixing the misspelling), and the save button enables. However, the change also appears at the beginning of the document. In this case the required spelling fix was adding an 'r' (occurence. to occurrence), so an 'r' ended up at the beginning of the ContentEditable.
However, in Review Changes (and the actual save), it then drops the original correction, and *only* puts the wrong edit at the beginning.",237057,43,,
-1.9440485623629797,2.1211739976005664,-10.359637355219958,9.85923072894438,1.0944364868431542,-1.7706489502800036,0.9222071738405067,5.174055677166119,-1.2723563715570059,2.628308567394545,1.095619350409661,-1.2340961606636416,3.4970985533797547,1.5579933173568163,1.1195063453384102,-3.7952617593228424,2.5483304827403774,1.091452418457211,False,c1,3,"Tried to duplicate this with FF 28 on a variety of typos on different pages. Ran into Bug 63395 a lot, but was able to save after using FF autocorrect to alter the typo text. (On a side note, hilariously, FF autocorrect suggests that ""autocorrect"" should be changed to ""autocrat"":))",237052,42,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 52372 has been marked as a duplicate of this bug. ***,237047,42,,
4.6939810007833636,-6.7862572975703594,8.292948421395563,-2.4702337021930685,2.3844540289268306,14.121896300356422,-1.7040580831363652,-0.6826726814225704,-5.724938272791685,-2.017401702034938,-5.1632783775961055,-2.6719526358984655,1.2939845925274756,-2.290259320851101,8.885032451408325,1.2263498062326739,1.1860522251904584,2.8137832833390335,False,c1,3,"No i don't know, it's a report from the VE/Feedback page.",237042,0,,
-10.450211095530259,-5.105333346917476,2.4211328477300773,7.446829716228661,0.8208456236542734,2.762286357409028,-7.887415092512563,0.265801462239909,14.431701131602352,-0.4036219829435863,3.0709603713810374,0.852473249583408,-0.10893773786185346,-2.8043421047115267,-6.457221230570131,-2.4786712963902464,-2.963214075431453,4.0989452337992205,False,c1,3,(Assigning to me absent confirmation that this problem is reproducible.),237036,0,,
0.2756100991915824,4.549747047777714,-4.848501370387988,-0.8595315967320545,1.6396979970249586,2.5477547450663884,-2.9043396828919805,3.039540018937901,1.6572951630596358,-2.941677899822534,-0.8688319010478791,0.6452625086176704,-1.1571792617291783,-0.7254517302808229,-1.1713026226703178,5.102892398319963,-2.842432494742185,3.309349985674904,False,c1,3,"(In reply to comment #0)
> Quote: Using Firefox 19.0.2 on Windows Vista, editing Relativity Media. Find
> ""subsidairies"", right-click, select ""subsidiaries"". The word appears changed,
> but the ""Save"" button is not activated.
Odd. I get the save dialog activated on making a spelling-correction changes in both Chrome and Firefox, including on that particular word in that particular page. Saved example: https://en.wikipedia.org/w/index.php?title=Relativity_Media&diff=563012676&oldid=559815961
Is the user using a non-standard way of doing the spell-correcting, do you know?",237032,0,,
-9.956095177824807,-4.574182274167443,3.4023499324470112,1.739908080932528,-4.427150607981938,-2.905781531796503,4.355279694113495,-6.809273799946598,-1.142463375876319,-4.417081918311239,-0.07855212788678578,-2.929411645395241,-2.4573274966491514,3.1662249487313368,-2.1781835028528933,2.3945665908269937,-5.389386413349758,-2.4618894911253695,False,c1,3,"We've now fixed this in master, and will back-port to production.",235877,1,,
5.3368882554350865,12.882884267207285,-7.015076047017401,0.2648861840983212,25.382154837975985,9.881984820734424,-1.9646538764275707,-4.2413723273970545,-2.0100724609531415,1.2630452634543508,-0.27550473544647924,-0.4287584482389821,1.3181102614142235,0.07171671523505174,-1.558819655810506,5.377901351911829,-1.8345234798434835,11.833568331637231,False,c1,3,This is a wikitext escaping bug in VE,235862,1,,
14.258058995186234,10.898390189232746,-6.4629257621116185,-3.4955850006111966,-5.630225618667671,-1.4645077768915886,-0.2707617614227864,0.9243867318456799,4.990503634671861,-1.6131780963951377,-0.3702062287826633,0.30693158425519673,0.14744636948643697,-1.2163678291550846,-8.033935555903405,-1.8763186867362518,0.5213204988124911,7.308465736534943,False,c1,3,"Screenshot of different phases:
http://cl.ly/image/1X0I281n1n0G
1) PHP rendering on Read
2) VE initial rendering after Edit
3) VE rendering after opening Template dialog and making no changes and clicking Apply changes
Dirty diff: http://cl.ly/image/241h1I3T1d2d",235857,1,,
-6.609681565600981,-4.528646983917071,4.57513940040474,12.512452504428376,0.9593237068684175,6.620604486147318,5.753541945386873,-0.3394669876872922,-1.478953589378094,-4.735228823798342,-6.513997652147932,3.3784305238182304,-5.179488273692012,6.369355530549922,7.080598612509607,6.501960254850728,-2.5430796372437183,3.132216932816012,False,c1,3,"It doesn't show in the diff, it only shown in the live rendering in VisualEditor.",235851,1,,
-13.737781877898403,-0.24459157697322986,2.6652083366557484,9.337610598760206,-1.3079676233543136,18.408811567738834,-5.663174052380935,6.9243711977326114,-4.41700477103249,-5.2041237345340665,0.19555882405927427,3.3197044649213625,-5.253625645819685,1.1773972119172111,-3.890551882206676,-2.951023797773019,-3.039000447879931,-4.542609394596089,False,c1,3,Can you create a broken diff on that article for me?,235849,1,,
14.340175573248052,-0.7957398845965251,6.095836188128315,1.4517110601574945,-0.2913570677128998,-1.4585008713378649,-4.587987010525571,-0.26142599286468093,-0.44402202226603227,-9.951700751038505,-8.0415357332047,10.599563069435423,-4.879310465168068,5.649036307933432,0.7305051179687947,0.8476576272012362,-2.2845949060673827,2.3327885144308067,False,c1,3,"As can I, hence the duplicate bugs. Firefox 22, Windows 7.",235846,1,,
-1.3768213439831207,1.6091189217270294,10.82126028079294,7.181218703712085,-15.198625692835353,0.3787518414299722,-2.9473758133272563,0.8170297650708013,-7.410817687314067,0.9776429537734721,-0.5840746802276948,7.209229501367207,1.8643585039292319,-1.6222800516811773,4.188363537100942,5.29136587202369,-0.8779541017896251,0.662249494380903,False,c1,3,"(In reply to comment #4)
> Can't reproduce this at the example URL.
I can still reproduce it :-(",235842,1,,
-2.8519029597837364,11.405343771848703,3.917937233287378,-1.783580321408916,10.943830578806775,1.2494160380391293,8.391863402129195,7.719676952784869,-12.895367893650695,-2.146394492590345,-3.4114229636717552,-4.656571680188913,1.7912452563909618,5.67379645808507,1.0490363775469431,-3.5703401519268607,-5.648719478195018,0.7332749197832436,False,c1,3,Can't reproduce this at the example URL.,235837,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 51014 has been marked as a duplicate of this bug. ***,235831,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 50909 has been marked as a duplicate of this bug. ***,235825,1,,
9.10406736963822,8.192559615430266,-1.8835527565528798,-6.761062269783895,-7.343485443037065,-6.657382180978618,-5.229228366372993,-1.2929319801460575,-0.4321798792897196,-2.1850454191121487,-1.4356640160127987,-1.0994378745925264,-0.08449216305869545,-0.8988133330652388,-3.056156661373369,-0.4377285896079792,1.709282758104476,-1.5125599272640855,False,c1,3,"Created attachment 12761
Template inspector after closing
**Attached**: {F11205}",235821,0,,
-9.137807686118098,-4.983971861078716,5.610832142612632,-6.646462482516561,5.911614442051112,-13.162724022449876,10.965472583922255,-8.630703702911665,-4.065367758713417,9.244019452622595,7.9810333347523255,2.7857280652910097,-5.559225206690363,4.971125059241563,-1.6455362023462323,3.2310978809897812,-1.1916944864158798,-0.2890066225591843,False,c1,3,"This is now fixed in master and will be deployed soon, probably tomorrow.",235778,1,,
-16.362038636826373,11.343145852535567,-10.17398639279677,15.42187070955949,9.075481547871167,14.78390958963261,-1.075182880917879,-0.23125300054513376,-9.160597033862192,-12.729438756949367,3.7190182211894216,1.795347412079269,-1.878548349651909,3.3903390185276843,-0.19422420612685487,-2.36332406546973,-3.740490143739203,-2.813787184913338,False,c1,3,We did this as part of the fixes to the toolbar.,235736,17,,
-9.007011101065778,-9.257279037399798,10.064815275708005,1.7796542691457002,5.459568008391429,2.0807495184641382,-2.040565619814112,1.3028645960432188,-2.544218684085982,-3.6368072978693706,2.151573708960343,-1.2241767377807373,-3.826905192779587,1.2415118696966136,1.1421872098929224,-2.023889804037775,1.5298013638804109,0.5082717713437934,False,c1,3,This is now fixed by the above commit; we'll get it deployed soon. Sorry for the disruption.,235407,1,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 50860 has been marked as a duplicate of this bug. ***,235390,0,,
19.351011822216336,2.58705933628222,-3.5571343801183244,19.182238229210462,2.17024206978126,-6.917340979264663,4.1658623742722085,-2.6922645529557756,-2.004641346688312,-4.844681862657815,-0.1960150301480028,0.7162440986330916,-0.41938696612633564,0.2992751756985368,3.523326351333119,5.746745601112259,-5.273022309634876,-0.7429217623823234,False,c1,3,"Confirmed in Chrome, Safari and not in Firefox, for whatever reason.",235382,0,,
16.143669521707942,-3.2911758181216513,3.7488989559380625,5.686377675666501,1.3237189173035553,2.2485292386023463,-0.5493384168208575,-2.600675379156924,-1.9877440247880416,-1.0182853836940695,-1.7720906339978093,0.7399589464000842,0.11769961136788343,0.1602787325642412,0.5485764882138171,-0.6412423982248678,1.9798747083010106,-0.7192947796057467,False,c1,3,"I just checked the editor on Firefox 22.0, and it does not scroll there (works as expected). The bug seems to be in Chrome only.
If it helps, that's the UserAgent for my Chrome browser:
Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36",235377,0,,
-11.816106948647306,-7.719281705657518,-1.5419153802060614,-1.5987254681886025,4.938979972658361,-6.265792103472944,3.9875814905188474,-3.7439239284806898,2.463054469583094,-0.3437753293381598,0.9688454878381001,1.8987463068250774,-4.611967175895802,4.410202721337276,2.1067859273256895,3.7739368461515608,-3.8392160901313828,-0.3550295292567167,False,c1,3,"This issue is now fixed (or, rather, the button is no longer needed), as we've gone instead with single-click-to-insert, which will be deployed in the next few minutes.",234285,2,,
-12.922313791570808,-1.3557018597202894,-0.6781955584871608,-0.20132008529699874,17.070122756449454,-3.2942352875102685,10.200560731038196,-2.9834364018940684,-5.245779709937663,-8.327167398747505,-4.82092103478942,0.24067549848392744,-1.946872159725185,-0.4128173952599691,3.779532404217149,2.7610783064450297,3.3356790462458434,-1.3648388743908855,True,c1,3,There is no longer such a button (as of a week ago).,234224,2,,
-11.247771939720455,-5.406122117446376,-0.8908773336196634,-0.8022845418511899,-0.25682865808379063,-2.6836152961721798,2.899292014512623,1.9468645945339311,-0.5906979527551226,-3.655222718448685,0.3980815239936967,-0.6528910013972444,-0.9052136983669012,0.2749317991452296,0.4777087078252462,-0.06789567386492612,2.2478175683783133,-0.664923135664246,True,c1,3,"Created attachment 12830
Screenshot of how it used to be
Note that though this is how it was. It was also true that when the text in the input field was very long (like, very very long, as long as the dialog is wide) the button would jump to *below* the parameter list (as opposed to directly below the input field or just stay where it was).
I propose that we either keep the current behaviour of the input field having a fixed width, but making sure that width is without the width of the ""Add"" button so that that one always stays where it should be (similar to having the ""Go"" button of a search field next to the input and not at the bottom of a variable-length and scrollable list of results).
Alternatively we could bring back the dynamic-width behaviour but when we'd still need to make sure it doesn't go wider than the width allotted to keep the button on the same line as well.
**Attached**: {F11129}",234218,1,,
-4.232176979295721,1.4244574599500996,-2.750859705614109,0.043878691481848975,-1.4171384163428886,-7.463613622058257,-2.0519573449772466,3.7539928404380514,-0.829059465777755,1.8767240616811218,1.260682475297124,-0.0333686166532674,0.4891039518443696,-3.182221190447474,1.228171689489281,1.295096944065775,-0.4712262142189068,-0.6746519806047302,True,c1,3,"Created attachment 12829
Screenshot of the problem (current version)
No add button anywhere in sight, users are likely to be blocked indefinitely with no ability to add any parameters.
**Attached**: {F11128}",234211,1,,
-10.67817819373602,-1.278058381125165,1.966847542611922,2.348565467611053,1.2214730156754818,5.01570669822139,2.8651543397814105,0.6565759387516754,2.7984222386547684,-3.4419951094407173,1.8790673681017283,1.6981571090620289,0.6222669789128776,0.7753571576013079,0.9586353431317165,-0.6063276358948433,1.324893718329818,1.8222819951078377,True,c1,3,"Though I don't know for sure, I think this is a recent regression. the button used to be where it should be (next to the input field). However at that time the input field width was also dynamic (widening as you type). I suspect Trevor ""fixed"" that odd overflow bug by moving the bottom out of the visible form area but probably tested it only with a small template where it was still in sight.
Adding screenshots for clarity.",234203,1,,
-7.634980247206341,-6.824176246731443,9.078412111709994,7.176366695082779,5.675194378790362,4.114116206915373,-7.17840537590921,4.28577689850814,-2.136104425913704,0.34487850875737625,-1.4912333880001252,-0.8797711083510835,0.6729905332010477,-1.4514369059150134,-1.6677142842828268,1.9324527759860723,1.376837658347735,-2.531422898350063,True,c1,3,Works for me. Can we twiddle with the prioritisation and criticality? This is a big workflow to have practically broken.,234196,1,,
-12.814690580052517,0.07610278474225929,-0.6225134874396443,6.444874021206163,-0.21254245994319554,4.880800387383466,1.0162359793123166,8.379506174306774,-0.7166170220114811,0.14851811962016548,-2.1307120334863767,-0.4302238174342463,1.7554761527666045,1.4982424120585958,1.6519508351501289,-1.3592163837244358,-0.22153246753365702,0.13996974572026044,True,c1,3,"We're getting various reports of this kind, let's try and keep them somewhat focussed on a single tangible thing. If you don't mind I'll turn this into:
The ""Add parameter"" confirmation button should be next to the input field
.. not at the bottom of the page after a potential long list of paramaters one has to scroll through to even discover the button.",234189,1,,
-7.833503147966113,1.1318633854486464,-0.31594439388751105,10.936795058652498,0.7193200563807771,4.498913402869224,4.2082916668712045,2.1651466881673214,-2.6762263885228874,-2.4351088696988246,1.5984555937297786,3.298809958056826,2.3184981972991636,-1.5580621982534324,1.8105799459955643,-2.0193663397729096,1.705984586231857,-2.250257707733203,True,c1,3,We really need a fix on this. I just tried to add a template (cite web) and was so confused I had to reach out to Timo and Guillaume to work out how in the hells you add a parameter. It's...tremendously counterintuitive on any template with more than 5 params.,234184,1,,
-10.040108650336386,1.8474172429081417,-3.4881361615216773,-2.2389776664348187,3.6758409539746513,-0.15381152917035656,-0.6856819216572188,7.525622956980919,-1.6399171917416333,-1.0043603744249179,-0.44487731986509016,-1.5661043758438091,3.089834207888691,-0.2827710835535642,2.503775667210447,2.0751940776551328,1.0875099524011165,-0.5462812070258845,True,c1,3,"Agreed. This is what I was going to add into a new feature request:
---------
In the current version of the template editor, the user needs to select a parameter, click ""Add parameter"", enter the value, go back, and rinse and repeat for all the other parameters.
There are at least two issues with this workflow:
* For templates with a long list of parameters, the ""Add parameter"" button is hidden at the end of the list, so it's not obvious what to do after selecting a parameter
*: Possible solution: Give each parameter a button that adds it to the left column (like a green ""+"" sign, or something)
* If the user needs/wants to add many parameters, the process can be quite long.
*: Possible solution: Add an ""Add all parameters"" button, and possibly an ""Add all required parameters"" button as well.",234177,0,,
-12.836038870551047,-5.6478582940336715,4.779352879349323,0.6767675827680542,6.376337936588554,1.0209183333469305,8.590248629542634,5.626162145948926,-5.489755008771245,-9.30417357450806,-1.885636472366179,2.651190126576137,-4.550860006735427,0.7466448961698637,-4.0177728123989045,1.7954240190767166,-3.3045282895480863,2.960704463187891,False,c1,3,"Maybe we could show these a bit more clear in the dialog, but closing for now.",233632,34,,
4.400327783185869,9.190318546612513,-1.6799241095382316,8.473622762539884,-0.7394522306558775,-1.3450015995595113,3.1035116059730825,1.146751047132358,-2.7060312321219433,0.8382332676086266,-0.320197775542975,-0.2891623005738184,0.7970478896926569,-2.1447571621320707,0.2756398626784913,-0.8775045337155292,1.4422249210143252,0.8605561959494259,False,c1,3,"(In reply to Alex Monk from comment #4)
> Am I right in thinking that the category data comes from Parsoid? If so then
> it might be useful to include whether the category is hidden or not there?
Okay so after discussion with James and Gabriel on IRC, for now I'm going to query the API when the category dialog loads to get this information. Later to be replaced by a general CSS cache API query (see bug 37901).",233613,32,,
-6.914468509657821,-2.8724912651441077,5.971140951040828,12.621779782784655,3.8408220075923616,-0.44046691207167754,5.702229792143662,-3.1011575985680833,4.136510264555809,5.177835220670568,0.475287248993262,0.8515127333327293,-0.39195078243941506,-1.8087792945762062,0.18210344459859185,-1.3076529440283333,4.588782929577022,0.08765470408158649,False,c1,3,Am I right in thinking that the category data comes from Parsoid? If so then it might be useful to include whether the category is hidden or not there?,233606,32,,
-2.7908664790944466,12.280769117458593,2.1251645662867347,10.592463653981776,-3.087113554470636,-7.936129974938602,7.129761717377269,5.553184012736974,6.769825286550848,7.890569015441255,5.205451913008806,-2.3210036357917,-4.738037427459831,-6.363637956311261,0.6785709401926749,-6.204702354872891,3.992956660552717,10.467040249256666,False,c1,3,Re-wording to be less confusing. Sorry!,233600,32,,
-7.147287884338776,-1.5831151194820539,10.381898090658634,-5.15487554080602,-5.227884318547346,11.151525754742472,-1.3947507339262124,-0.6895422071221357,5.534525133157569,3.164451746625141,-0.9365404501182222,0.6662475543696242,1.9818752991134687,-1.8526067414053642,-2.0323968234167835,0.6328425186042068,-3.3289787462267983,3.466228403307467,False,c1,3,I think I'm missing something here - it appears that I can see hidden categories and add hidden categories to pages using the categories tool. Is this bug still valid?,233596,31,,
-10.557125359580212,9.75067620601476,-6.561155319655471,8.9367867946266,0.3453187363803494,-1.3162689865215693,4.645115152780535,-5.77452339222059,3.9828509544482404,0.6320622618469738,2.1328361871103887,-3.7927015380614475,-1.411279797377222,0.5746472767615436,0.016185609454955063,-1.0950425986948322,1.6957664584965213,1.8683945344156068,False,c1,3,"""A late answer to the question of whether there are hidden categories that are actually embedded in articles instead of templates: YES. For instance Category:Year of birth missing (living people) is directly embedded into some tens of thousands of them""",233592,0,,
-10.262941876400182,3.5000807622368413,-9.037763109091998,-3.211531405292961,5.0807642241216335,-3.7897855833723746,-6.72443586456111,-6.205858030426466,-3.428413411824989,-0.18630657237871073,-2.059095158813521,1.7036529941812217,-3.329411471222237,2.296060110217957,0.1868727730887194,1.0903868296918096,-0.32439453618584335,-0.6276282215738869,False,c1,3,"
*** This bug has been marked as a duplicate of bug 51217 ***",233093,2,,
-7.667587186353402,-5.5943647329296216,-2.2820784173630893,-2.632717839481584,1.484342277509315,-3.3733060390277387,-2.6151378074517337,1.2764978747749973,-1.2621868806572552,-2.860559963019665,0.8438893359362054,-2.1646749103866387,0.10287550174085602,2.4406266105139567,0.05442064948981562,1.5928196170894586,3.6888671336115,-0.6203954514943613,False,c1,3,"A minor change in a completely unrelated part of the article causes a copy of the broken table to be injected into the article, and a ') is also included. Upping priority/importance as it should at least ignore elements it doesnt properly understand. The was not so broken that the wikitext up to the
should have been ignored.
I am able to reproduce the ' Is there anything left here to do that isn't bug 60358?
I believe that that will complete this.",232668,59,,
-8.483338527410993,-7.493876887800774,7.0092197886253675,-3.9333544122931663,5.985859687903792,-10.676490883678273,2.672739729970681,-6.706360779440658,-2.1927838704955955,12.115325630297905,-3.9514009118401057,-0.6059688480045278,6.761460435670215,0.4961557005903279,1.212623582035015,-5.016448886930121,-1.3659380784471011,-1.2510796462297709,False,c1,3,Is there anything left here to do that isn't bug 60358?,232660,59,,
-8.65591955266275,-7.051255340126215,0.91148055826618,-4.665964093902188,1.5134932628930056,-2.061897976915496,-1.985439347501206,-1.9020078750845562,3.15690478473348,-2.1235889749148265,0.39702051470024935,-2.558141263991289,0.6029516250492515,2.977058739872005,2.265484252571582,3.198591401956997,0.6568125842508137,0.6481561477137756,False,c1,3,"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...",232651,23,,
-8.463103031968604,-7.899258635116441,0.19704734746481822,-1.8616803070508503,0.6569985847695019,-4.9994377404778145,1.1432159980578174,2.8481362118911857,1.5650326666716887,2.39043033898062,-0.8090976867950794,-3.8658720038015364,2.318924834000823,1.2151475524744344,1.6095354100459458,0.55823449397939,1.187730195864824,0.9041408366275676,False,c1,3,"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.",232642,3,,
-11.160856310557367,5.078228901167634,-4.375238488827652,-8.07972681404349,10.318482942375514,0.669280776496608,4.461156339236407,0.2763901564319917,5.149606888331469,-2.160233826433194,-0.8444821151005324,0.5183947767878587,-0.683880910343496,0.07459844822239581,-0.5485479853912412,6.81792457139713,1.0246560028495504,6.904835658196731,False,c1,3,Not enforcing mandatory params is a bug in either design or implementation.,232636,2,,
-12.854363577934867,-4.6745780005924225,-1.7200916820693712,2.7727409846552433,1.679578053027619,-3.4774296610473883,3.4220058258016675,3.4565784484642377,1.3151139171065933,-0.18374072818539755,-0.41711876457327746,-1.9749823136959774,1.70683782988531,2.3552531363516076,3.4468639833008297,0.9781649686122846,1.71896326008724,-0.1321356981288564,False,c1,3,"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.",232631,2,,
5.18613592523959,-2.2617895261492507,9.998024362397727,16.11505116921243,6.302706000618521,-4.420118540155627,0.2944184313667506,1.512121199629393,0.19547672068213506,-13.091378997000097,3.986545698613524,-0.47120888567064156,0.17854286637100714,-1.2732849533921893,-6.313455266556014,-3.343138319792464,-0.8661831744180916,-0.5123045091012206,False,c1,3,"Indeed, I gave up doing this for the Portuguese version for now:
https://pt.wikipedia.org/wiki/Template:Info/Taxonomia?uselang=en",232628,2,,
-6.6697883649961645,-6.588430961979942,-1.8685947091642023,0.08024836559776816,2.3922283906540436,-2.174957166337199,-0.4392582445615041,1.9186308930111102,-1.0941255261462803,1.8636392005385582,1.5557236430828656,-1.0125978379324359,0.6830875406810857,3.0228350496784397,1.9360409316596714,0.9757617092694963,2.726723036283308,0.6111196162146322,False,c1,3,"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"".",232625,2,,
18.245662991688704,0.5057277845631347,-0.3872709297456536,-2.7225667713588244,6.098533108241625,0.6363757696648005,3.7172344207805263,7.899011882270542,14.47582088146748,-2.873745679211387,-2.4809814520132836,0.6203187626660931,1.011360268485344,-2.405811452786164,-2.247298772506374,-0.4897534308316396,-2.30254218802215,5.516198730858413,False,c1,3,English Wikipedian Joe Decker recommends indicating required parameters perhaps with the standard red asterisk.,232622,1,,
-9.07593402064757,-1.363034300841786,-6.299330816180469,-6.598000028564075,0.04835581787161125,-7.6753667036618705,-10.109203237375718,-3.866207916529184,-3.7821452284805908,-2.5995365996098343,0.8349261186127497,-7.166925347465758,-14.50126027499308,-8.118473098046374,11.759834708373688,-7.952421211184966,-1.76776847155035,5.117239211840985,False,c1,3,%%%*** Bug 51186 has been marked as a duplicate of this bug. ***%%%,232617,1,,
-13.930149757486012,-4.410091186305053,2.361954357711138,7.225206971108976,0.5161130578855815,-2.983909271864839,11.256778668373412,-3.6691725013085033,-2.0981813217809657,-1.7640914043620648,0.9203624686940121,-8.09286749375799,5.8569704893635235,2.3201450993600723,-2.925451953054225,-4.798465141527847,-1.1221570779613925,7.132357487962048,False,c1,3,"Leaving at ""recommend"" for now since we can't fully ensure that requiring all parameters is consistently the desired behavior.",232603,1,,
-4.704884463141557,2.265248303497346,1.4513068988793338,1.0495234987511832,-2.311481592948966,1.8968084705925445,-0.908715396994122,5.6894985188603755,-3.9437223444453924,0.7742149162928476,0.06328267261229747,0.20230222059395153,0.8729435766644769,-0.8434379929598897,-0.10800564603278717,1.0759100621882927,-2.101509593713644,-1.6484526861281472,False,c1,3,"(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? …)",232594,1,,
-13.593967191679267,-3.1601077239318283,-2.6092304987985786,-5.204159154144513,7.925552836424817,-3.197196012543813,6.587748683708101,7.129189119894851,0.7725335795783317,-3.351889944380863,-0.13289156432280458,-1.1655265111355528,0.8634850913495695,-3.76025691846269,-4.667945515225297,0.7953621982432746,0.39241619689393537,4.793297059754627,False,c1,3,"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.",232580,1,,
-8.202529868351931,-12.152877771566281,11.9997004894992,9.364566998209577,-4.805747840752121,-5.000244209819304,-1.3977320141781107,6.268537500426876,-0.5728867631030672,6.059633386068839,2.0734024280033383,1.071447273335731,-5.58347017940442,-1.3581306745848938,-1.231379351437343,-1.1165837930498674,-2.7872850741292323,2.6061400283781047,False,c1,3,"I believe that this should now be fixed; marking as such. If you can reproduce, please re-open.",231514,1,,
-13.290550502462953,-3.111028417124066,0.07347127298211964,6.496256635983899,6.198226931854892,2.5028922959356823,-0.07660436229830125,-1.5891534557611648,-2.2669962573253084,-1.6195907227073016,0.6562521302267684,-2.1171101374129195,-1.1550672958851678,-1.565746748896004,-2.900375076503499,-2.0768435050328065,-1.3073669176644807,-0.6597747808450496,False,c1,3,"We believe that this is caused by a caching issue; a big change to how the CSS for dialogs is loaded is coming in this afternoon's deployment that (hopefully) will remove these issues, so I won't close this right now, but it seems likely that we will have fixed this by the end of today. Sorry for the disruption.",231510,1,,
16.202687888002487,-6.474474485781521,4.170448725503911,20.501096677514468,-5.036779743000082,-7.804092007795063,3.604640954427529,-4.168479384400907,-3.713183062932999,-4.8344902320726,-4.816146218950026,5.916626449286386,-7.473249452129054,6.106389026686691,2.1207035013342246,5.665695201133065,-3.6921960414265347,0.8827058882995016,False,c1,3,I can repro in FF20 (in Vector too) but not in Chrome 28.,231506,1,,
-1.9632680089659047,13.597359094806343,1.9438066583075742,12.449495406021521,-4.1634450715987406,-11.564196136450075,15.432188957274105,-9.142250270550228,0.7158714395189323,-8.30120620216602,-0.923779672130745,-1.605742361223467,-4.951144780594035,-0.10870300834318214,-5.358299063951273,9.502441887353449,-4.829341923688754,13.678582274865928,False,c1,3,Also happening in chrome.,231500,1,,
-9.07593402064757,-1.363034300841786,-6.299330816180469,-6.598000028564075,0.04835581787161125,-7.6753667036618705,-10.109203237375718,-3.866207916529184,-3.7821452284805908,-2.5995365996098343,0.8349261186127497,-7.166925347465758,-14.50126027499308,-8.118473098046374,11.759834708373688,-7.952421211184966,-1.76776847155035,5.117239211840985,False,c1,3,%%%*** Bug 50738 has been marked as a duplicate of this bug. ***%%%,231494,0,,
-4.75038959765931,-1.1305850507380075,-7.116489249041769,-6.777780072956781,1.1315663717809077,-5.806605414849703,-6.221345568852436,-4.347503543501238,-2.787808465034576,1.7886244195241314,-0.3719643385200697,1.5787085121717617,-2.616553284709334,1.9016064388364196,-2.5082222963369993,1.523883441366291,1.105429599426221,1.3375070067442807,False,c1,3,"* AbuseFilter is bug 50472; resolved fixed, and will be deployed tomorrow.
* SpamBlacklist is bug 50826; resolved fixed, and deployed yesterday.
Marking this as a dupe of 50472.
*** This bug has been marked as a duplicate of bug 50472 ***",231444,2,,
-3.6080230192424296,3.193157615476334,-4.659523292796962,5.69923462697176,-0.558899336414532,-0.28666452297763634,-2.121775049914323,0.6377409814519088,3.5704900448387775,10.46405256652467,4.4746617791792795,2.930514047759991,-1.0949712865777983,0.814590388167568,1.227979502154548,5.090968529430424,2.26116959090219,4.452498443927617,False,c1,3,"Bumping priority & importance as proper integration with abusefilter must be a blocker, I would think, as rules are being written to prevent VE edits that are destructive to Wikipedia content.",231436,2,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 50817 has been marked as a duplicate of this bug. ***,231333,0,,
-10.28801505377687,-4.369041739650644,6.50038702098089,12.283067277175297,-3.6144271996258306,3.074242494574989,0.23756946362238374,-1.7086700660426177,-4.849894043191802,3.504374887684092,-2.911520859092571,-1.9260815885902383,0.8053326123570441,-2.8599403948130213,-2.316064864220554,-3.605525771474045,-6.049824581185995,-3.0513313241519104,False,c1,3,Merged into master; we hope to deploy this soon.,231326,0,,
27.008741230383833,13.721270640839276,21.30706118200309,-4.723230967140985,-4.827984055119239,-17.123252896213987,-17.198955351059865,3.72596730067129,-3.021190828438746,-8.598211859047556,8.884342146896351,4.827203335718054,23.115860291390945,-17.13845860001286,15.783817570142695,18.90406890915238,-4.7188595764974846,-1.1170266757025265,False,c1,3,Confirmed.,231306,0,,
18.013386480279024,-3.2722350001999203,-4.20192930052712,14.79591741420886,6.970441638337297,-7.22924471856044,-1.4672595467082221,-3.0351645062894397,-2.7273284204001182,3.808763929336042,1.3908160663731501,1.5187373948022138,-0.855878025448962,1.9047506804299343,-3.2654073132897983,-3.926674863717911,4.747167456551827,-0.9130676230556802,False,c1,3,"The (re)fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.",231175,14,,
5.025310593074858,3.2660137246595475,0.711175118461234,9.147767840303603,2.79699094913874,-5.543486143345809,1.4747791796588743,-3.8529418701099325,-4.32939881157347,-0.39214409783552595,-2.4822260204783606,2.7527463386132203,2.6868157824905436,-2.4536130072350186,-3.968827041801496,-3.0477063359756023,-2.108379907333001,3.402924016600624,False,c1,3,"At bug 53332 comment 0 Elias Hedberg notes that he encountered this bug while using Chrome 29.0.1547.57 running in OS X 10.6.8
Previously this seems only to have been encountered in Firefox. Will that affect the pending patch at all?",231168,12,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 53332 has been marked as a duplicate of this bug. ***,231165,12,,
-11.289189990438512,1.025808661740676,-2.7140965113084308,-1.052395442963638,1.0788019432865763,6.106943947807871,3.6040331788336566,-0.2720202817024222,-2.697778043166461,-0.16214772866827687,-0.3099878774561571,-1.2511746953608842,2.5077408016659586,-1.3518159065818196,0.7216901856097606,1.2448091117799087,3.254514492331348,1.0827712568231234,False,c1,3,"BeroBurns at en.wp today reported experiencing this bug:
""The save form does not allow for a keyboard backspace or to highlight text using Shift+Arrows. The only way to edit your description of the changes is to highlight the words you wish to replace with the mouse and retype.""
I personally haven't encountered it since my comment above though.
What is the current state, it's had a patch waiting for review nearly 20 days and is still targetted for the release a month ago yesterday?",231162,12,,
-10.500289412365898,-6.79739013429903,6.668105070107629,1.3097914320310746,-2.761353440517463,0.9124442176068523,4.430509515946111,-1.3312795518417748,-0.11508570952044184,-4.923785140076273,1.3632663472310655,1.0083862368415355,-0.3383395703772001,1.1929221477878904,0.3855860892759462,-0.8927611435243672,0.2732059624836579,-2.2129414843294906,False,c1,3,"I do have popups, hotcat and section edit link for the lead section installed. Plus a couple of other things a conversation on the feedback page the other day established as being on by default.
I tried to reproduce this when logged out, and couldn't.
I then logged back in and tried to reproduce it and again I couldn't, even with no changes to gadgets. I didn't try to replicate the exact edit I made though.
Earlier on today was the first time in a while I had experienced it though, which suggests to me that there is probably something more complicated behind when this happens and when it doesn't. I'll do some more detailed testing when I next get time, as it's too perplexing for 1:30am!",231151,8,,
7.266325386241315,-3.632028917129748,-2.0701391186251934,4.559135456586395,-0.4492543693578561,1.32760771081049,-2.1904645387420105,0.5264076164704197,-0.35027684999763037,-1.0039638895943197,-0.9694948609493204,-1.3405623924426688,0.1144189614473694,-0.9992820581290188,0.05297187509097068,-0.1878030647231319,0.19083698945093988,-1.6260754839324405,False,c1,3,"(In reply to comment #12)
> (In reply to comment #11)
> >
> > With what browser?
>
> I encountered it using Firefox 23 on linux, Tathbelin didn't note it in their
> report but I'll ask.
>
> Sorry
OK, well, it works fine for me on enwiki right now in Firefox 23 on Mac and on Linux (doing the ^, the <, the Esc and the ""return to save form"" ways of bailing). This is perplexing. Do you have some odd gadgets loaded - does it still occur if you switch all gadgets off?",231142,8,,
7.0806196618785044,-0.8782672640691445,9.876532788580741,7.0599630926878,-14.541216951836788,4.8235960146745605,-4.744390688016247,-0.7924196324856342,-5.3565975519838815,-2.0771962790499323,2.5876698004837504,4.076643784750046,1.1296375240803722,1.0986711084374103,3.7141079432029054,1.6331639779342892,-0.4677152299429621,4.73232189533185,False,c1,3,"(In reply to comment #11)
>
> With what browser?
I encountered it using Firefox 23 on linux, Tathbelin didn't note it in their report but I'll ask.
Sorry",231134,8,,
37.7833723163655,2.7817503229293834,-1.4738921956960005,1.9932419966461943,-2.280025450070413,-3.6161141254024987,-3.167357949177455,0.687320935301442,-1.3032296908056007,-0.36303932715162857,0.25449039579415667,-0.43811071430204773,1.3747258758702712,-1.6856144424629438,0.824112817442638,2.0010482503830054,-0.2701473422743384,-1.6495874771562253,False,c1,3,"(In reply to comment #9)
> I've just experienced this in my sandbox making this edit:
> https://en.wikipedia.org/w/index.
> php?title=User%3AThryduulf%2Fsandbox&diff=570859913&oldid=570858997
> (testing for bug 52399)
>
> In this case the series of actions was:
> 1. Make some edits
> 2. Review changes
> 3. Return to editing surface (I can't remember whether I went direct using ^
> or via the save form using <)
> 4. make some more edits
> 5. add an edit summary
> 6. review changes
> 7. return to save orm
> 8. attempt to amend edit summary, but encounter this bug
With what browser?",231126,8,,
1.9631686425431418,-3.14060376267164,6.693324257320862,4.131732171892343,-0.43833952686769173,4.181087992703894,1.7984137755293172,3.054574923976598,1.650387968676035,-7.512065496800224,7.55257876917525,4.829485788216322,4.78769975685158,2.3763642017970046,3.6169600951027414,-0.17194665248213203,-0.22439935537411956,3.1916982023742793,False,c1,3,"Nearly simultaneously with my writing the above comment, en.wp user Tathbelin reported on the VE feedback page:
""I had the Problem that while I was writing my Change Summary after editing the page I wasn't able to delete what I had previously written i.e. couldn't use delete or backspace.""
The edit in question was likely https://en.wikipedia.org/w/index.php?title=Henning_Wehn&diff=570856495&oldid=565884244",231115,8,,
-8.63579618582502,-0.2923225464646748,-4.783206401747719,-7.427772953730256,-6.96060887042621,-2.4087989485496646,-3.630491663793963,2.7737071521279826,-4.060780771631156,-0.2071446112377089,-0.873163129770278,0.33086176059034056,0.16149513652166902,-0.3274346609700034,-3.4220971854470448,-0.7167624405267206,-1.3617456115069049,0.6635184043760955,False,c1,3,"I've just experienced this in my sandbox making this edit:
https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox&diff=570859913&oldid=570858997 (testing for bug 52399)
In this case the series of actions was:
1. Make some edits
2. Review changes
3. Return to editing surface (I can't remember whether I went direct using ^ or via the save form using <)
4. make some more edits
5. add an edit summary
6. review changes
7. return to save orm
8. attempt to amend edit summary, but encounter this bug",231105,8,,
1.9316884098066112,-7.001403601050034,0.5565329299524708,17.096438523621124,-2.1338741141704265,-8.302975082502803,2.9263993532590007,3.7313885721689704,1.2283668349336765,2.4150456394027,-0.6873850635597707,2.3504877174415615,-2.7218336421876312,-1.5508260903494786,-0.18091433160156356,-0.34347917257470284,-1.3670081515664503,1.3567590521539734,False,c1,3,"I believe that this is now fixed, having followed Chris's very helpful steps to reproduce in bug 52733 comment 1 - tested in Safari, Chrome and Firefox latest on Mac just now against wmf14 as deployed on the Wikipedias right now. Marking as such.
If you can re-produce, please feel free to re-open.",231096,8,,
-10.263153995059014,3.499742197584826,-9.03759967743119,-3.211685886629974,5.080686584257533,-3.7896938215017837,-6.725739533153484,-6.2066412806210804,-3.4297807214638123,-0.18608353087102714,-2.0594897027187664,1.7036392164824514,-3.331044677007047,2.296360693954399,0.188444982030191,1.0899625797488244,-0.3251293279210525,-0.6288121632349606,False,c1,3,*** Bug 52733 has been marked as a duplicate of this bug. ***,231088,8,,
-7.002310361843757,0.12175146707959073,2.6426723598188095,3.510296312173617,-4.5123967115460895,7.105666704119564,-11.880009307358476,-0.6375532354120389,-7.394843010519692,-14.913187313506059,2.9069688730277212,9.924522418461251,9.839362285600942,-2.744449598285231,2.5681817663052398,-1.896165806368971,2.5683266196239694,0.892244282772777,False,c1,3,I updated the summary per comment 5.,231081,1,,
1.8621763440838803,-2.2449982166612568,-2.1329687228428083,7.427012999584109,11.179789615668678,5.4445117849068225,-2.3805003369338573,-8.655857728653789,0.8789348214172714,3.7311670133863126,-0.9262118794278957,-3.217144277013962,2.9068871686352153,-3.2622318574436195,-0.8448264801427567,-2.3050977784535234,-1.9245823835418512,-2.8507381397929925,False,c1,3,I think there is no connection with ULS for this bug. The bug exists at ml.wikipedia where no ULS is installed at present.,231077,1,,
-1.126373313216611,0.02419668018670329,-5.691158112004352,14.374502341400076,-1.8018647144244788,-11.628490956850882,-1.0754627783689301,1.2562677128937692,-6.343952420923269,-5.838992886181603,-4.602200480879446,6.0443911432857,6.240153681981398,-5.302678547543572,0.08161683675667364,4.239158927936112,1.5126711828396657,5.641799255044193,False,c1,3,"As per comment 2 and comment 3, changing the component back to VE.",231073,1,,
-5.0589125718816295,-0.7464267605512624,-0.42082879430108977,-4.312508188098013,-4.808493988488301,-4.506047210152701,-0.8294019552079881,4.245391611387209,-5.27668155341917,-1.4238777424669626,-1.1423570785703805,0.18966552484636168,1.1979773674543686,0.42807100460448244,0.5136574534308931,1.1585322958459523,0.6247929952928402,-1.5685842780578068,False,c1,3,"(In reply to comment #2)
> Open the the dialog for entering reason? It disappears after I click ""Save
> Page"". How do I open it again?
A bit more precise:
0) Navigate to [[Mariposa botnet]] and edit the page in the visual editor.
1) Make any textual change - just add ""Test"" somewhere for example.
2) Click ""Save Page""
3) Now, the save page box titled ""Save your changes"" should pop up.
4) Close that box by clicking the ^ icon in the top right of that box.
Now, you should be where you started at step 2
5) Repeat steps 2 and 3
6) Try to add a text as the reason, then press backspace to delete what you just
added.",231069,0,,
3.420590786416133,-1.6185538776824053,1.2664474448717633,2.979840338877338,-0.7538045277145446,2.4351563718439184,-0.5534659379030664,-2.807659197113766,-0.8362606702276478,0.10387162570687725,0.6253881501986366,-1.4861039993013097,0.21554290196906578,-0.8311226361233828,0.17529059375335532,0.27200338319329287,1.6013814971508031,-0.2659751552574363,False,c1,3,"By default input method from ULS is disabled in en.wikipedia.org. ie by default it does not do anything on textareas.
Even if it is enabled, there is no input method for English except IPA which optional.
So in the case of the above bug, before mapping it to ULS component, please tell us whether input method was activated from the cog icon in the languages menu. Also let us know whether you were using IPA.
If this is not the case, the component is not ULS.
(In reply to comment #0)
> Steps to reproduce:
>
> * Navigate to [[Mariposa botnet]] and edit the page in the visual editor.
> * Make any textual change - just add ""Test"" somewhere for example.
> * click ""Save Page""
> * Adding a reason doesn't matter. Just click to close the save page popup.
> * Immediately open it again (Don't click anywhere else)
Open the the dialog for entering reason? It disappears after I click ""Save Page"". How do I open it again?",231065,0,,
-0.19298450840461534,-4.932635016042088,-3.107111238716601,2.1995170488573113,-1.6996788216423289,0.06699709595762293,-0.054223117563962475,-2.001981385718726,3.2441137950267134,0.7541703893279417,1.6889618541877867,-1.5797880757734255,-2.204089861528813,-0.3289037545395863,-0.5430442135267914,-0.7705361245397406,0.41515947300116895,-0.3734731409722789,False,c1,3,"Yes, this is a really horrible problem that we've narrowed-down to be related to ULS's munging of