[00:10:06] 10VisualEditor, 10Graph-VisualEditor: Bottom paddings visual issue - https://phabricator.wikimedia.org/T119017#1815628 (10ferdbold) 3NEW [00:19:00] ferdbold, around? [00:22:49] yes [00:22:52] James_F: has the expression "visual editor" ever struck you as very meaningless? it just struck me after somebody pointed out how ridiculous it sounds in Polish translation. [00:22:58] have we ever considered any synonyms? [00:23:40] we're thinking about using the equivalent of "direct editor" in the translation (as opposed to "source code editor") [00:23:42] I actually was about to message you as I just noticed that wgGraphSpecs doesn't exist in production, is this normal? [00:23:48] (yurik)^ [00:24:38] ferdbold, how do you mean? it should be there if there is graphs on the page, and its in the page preview [00:25:28] i just started writing the extension update to load ext.graph.vega[12] (depends on ext.graph) if there are any graphs present [00:25:31] Look at https://www.mediawiki.org/wiki/User:Ferdbold/Sandbox, the graph there renders fine but mw.config.values.wgGraphSpecs doesn't exist if I inspect [00:25:32] but only in preview [00:25:56] what sorcery is this [00:27:25] * yurik is looking... [00:28:25] MatmaRex: It's the standard term. [00:28:36] MatmaRex: The other one is "online rich text editor" but that's worse. And longer. [00:29:31] ferdbold, i just opened your graph, clicked "edit source", clicked "preview", and did mw.config.get('wgGraphSpecs') in console - and it gave me an object [00:30:18] i guess your concern is that the mw.config.get('wgGraphSpecs') does not work when you are in VE, right? [00:31:22] yurik: yeah, since I'm relying on it to rerender the graphs after a save [00:31:35] hmph. [00:32:15] yurik: if you open the same page in VE, or just stay in read mode, it doesn't exist [00:32:47] 10VisualEditor, 15User-JAufrecht: Consolidate VE Planning efforts into one backlog - https://phabricator.wikimedia.org/T102262#1815799 (10JAufrecht) [00:32:48] 10VisualEditor, 15User-JAufrecht: Align all VE tasks with higher-level Goals and Epics - https://phabricator.wikimedia.org/T102267#1815798 (10JAufrecht) 5Open>3Resolved [00:33:17] yurik: huh, so it does exist in preview. is there some reason why it doesn't anymore in other modes? [00:35:01] James_F: by the way, https://en.wikipedia.org/wiki/Online_rich-text_editor is horribly outdated. like by at least five years, which as we know is two centuries in internet time. [00:35:26] MatmaRex: Yeah. But I have a COI so can't edit it… [00:35:42] pff. [00:36:00] yurik: i'm noticing that in Graph.body.php you're only adding the jsconfigvars on preview, I suppose that's what changed [00:36:04] do it with your volunteer account, everyone knows you're an entirely different person when using it rather than the WMF one! [00:36:28] ferdbold, that has not changed in ages [00:36:48] ferdbold, the idea is that we only add the spec IIF we use client side rendering [00:37:08] yurik: oh. so having the vars everywhere else was a fluke? [00:37:31] since in production we rely on $wgGraphImgServiceAlways [00:37:35] where else did you see it? [00:37:51] because otherwise every client out there will have to download the graph spec [00:38:00] well on my local MW i can see the vars defined everywhere as long as there's graphs on the page [00:38:01] and the vega lib, and d3 ... [00:38:25] ferdbold, of course - because you don't have graphoid running, by default it uses client-side rendering [00:39:02] yurik: is there more to enabling graphoid than adding its role in vagrant? because that i've done [00:39:25] so for you we need to somehow get the graph spec (which is the same problem as with the "make interactive" patch) [00:42:08] graphoid is a bit of a pain - because you have to tell it where to get the specs from [00:43:01] ferdbold, tell you the truth i think vagrant graphoid role is a bit outdated [00:43:21] mostly because its "run as service" part is broken [00:43:42] but you don't need that really to develop VE [00:44:05] ferdbold, what's your OS? [00:44:16] yurik: os x 10.11 [00:45:31] ferdbold, try this - clone graphoid service in your host somewhere, run "npm install", and if successful, run "npm start" [00:45:55] graphoid, being a node serviec, is much easier to run on the host than mediawiki [00:46:26] ferdbold, but again, i don't think you really need it [00:47:20] simply set the $wgGraphImgServiceAlways=true and $wgGraphImgServiceUrl='anything', and your static page will simply look staticy )) [00:47:35] i mean - it will look like the image is broken in the HTML mode [00:48:32] but when you click "edit page", you will need to switch to live rendering mode somehow - download the spec, the ext.graph, and render [00:50:39] well the problem is not really that I need the graph to be static, I just need the graph-ids to be refreshed after a save no new updated graphs are displayed after a save [00:50:50] yurik: i don't need graphoid for that [00:51:38] yurik: right now what happens in production is that updated graphs are not displayed since their graph-id is now invalid, so the editor needs to refresh to see the graph again [00:52:26] yurik: i fixed that particular problem a few months ago with https://gerrit.wikimedia.org/r/#/c/227332/ but now that wgGraphSpecs aren't anywhere, we're back at square 1 [01:04:49] (03PS1) 10Jforrester: WIP: Death to Cite code [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254082 [01:04:49] ferdbold, but this is strange -- https://github.com/wikimedia/operations-mediawiki-config/commit/442f7d5e6fa390901d6cf960546a3b015c52eebb [01:05:03] may 11 is when i enabled it [01:07:03] ferdbold, when you say graph ID, do you mean the image URL that HTML generates? [01:07:19] e.g. https://www.mediawiki.org/api/rest_v1/page/graph/png/Extension%3AGraph%2FDemo/0/d243aa924db2f82926e0f317217fcce591fe8cd4.png [01:07:40] (03CR) 10jenkins-bot: [V: 04-1] WIP: Death to Cite code [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254082 (owner: 10Jforrester) [01:08:13] jenkins doesn't like James_F's code murdering [01:09:10] yurik, i'm talking about the hash that is stored as a data attribute on .mw-wiki-graph nodes in the DOM [01:09:33] the ones that graph.js tracks to tell vega what is a graph on the page and matches with wgGraphSpecs [01:10:02] ferdbold, but those hashes are generated (at the moment) by php's graph extension during page save [01:10:30] https://i.imgur.com/zuGQrYX.png [01:10:52] and when alwaysStatic (production) mode is on, you won't get the
with the dom node, you will simply get [01:11:13] it does render an image, but it's on display:none and the actual thing being shown in a canvas element besides it (is that what happens when graphoid is off?) [01:11:35] correct, if graphoid is off, it renders the canvas image [01:11:39] the hashes are generated on page save, but that's not the same hook when VE triggers a save [01:12:09] but with it being on, it should only show [01:12:23] or at least *something* else doesn't fire the same way when we return to read mode after VE save [01:12:53] well, tell you the truth i have very very vague idea of how VE and parsoid cook it [01:15:05] i simply generate the HTML - either the
with a hash id (in preview mode, or when there is no graphoid), a
AND an if this is a regular page render but in case there is an old browser, or just the for production [01:15:10] ferdbold, [01:15:11] ^ [01:16:50] yeah, that works fine. I wonder though why those graph-id are not being regenerated after a VE save, since afaik the page does get parsed and rendered again [01:22:22] yurik: okay so after talking with VE folks it does *not* get parsed again by the server, what is being shown on screen is actually the generated parsoid html by VE (which should be the same thing the server renders anyway) [01:22:56] yurik: so this is a problem becuase the graph extension does not get notified that there are new graphs to render with new IDs, hence the new graphs not being displayed [01:23:19] yurik: could this be a bigger design issue with the extension itself? [01:24:17] ferdbold, i guess we should review the pipeline, especially now that restbase is introducing data storage [01:24:28] i will write something up [01:25:30] yurik: awesome, let me know how it goes [01:26:01] basic problem - some "data" has to be stored somewhere by the ext and easily accessible by graphoid [01:27:54] "storing" is done when parsing (e.g. page preview, VE modifications, saving) [01:28:43] that data should be easily accessible by either graphoid when rendering an image, or by the frontend - when switching static->interactive [01:29:52] yurik: baiscally this is why you came up with storing it in mw.config [01:29:59] right? [01:30:37] ferdbold, well, graphoid was an afterthought, initially it was designed to always be rendered client-side [01:31:12] yurik: well specs are always in wikitext at some point, couldn't both the client and graphoid access them from there? [01:31:14] which meant that HTML would always contain a contain the spec [01:31:20] or is that not what you meant by "some data" [01:31:29] some data == spec [01:31:54] ferdbold, and no, wikitext is not the same as the spec [01:32:00] because it could be a template [01:32:39] yurik: couldn't graphoid an abstraction level where it could reconstruct a spec made with templates? [01:32:45] e.g. in a template: ...{{{param}}}... [01:32:57] (i don't know the PHP side of it so I could very well be wrong about this) [01:33:12] graphoid have an abstraction level* [01:33:38] php simply takes whatever is between the tags, and uses template parameter expansion method (from parser) to convert it to a plain JSON [01:33:48] * gwicke has been suggesting that to yurik for a while now [01:34:03] (03PS13) 10Alex Monk: [WIP] Single edit tab [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/248369 (https://phabricator.wikimedia.org/T114530) [01:34:26] gwicke, which part? Btw, i followed your advice - graphoid now supports "version":1 value in the spec [01:34:40] James_F, did you see my preferences screenshot? [01:34:41] thx, i should have gone that route - took me a while to figure out all the moving parts [01:34:47] the 'no templating in specs' part [01:34:59] oh, no, that i disagree - extremelly useful [01:35:11] most of our graphs are done that way [01:36:03] ferdbold, so i'm not sure what you mean by graphoid having an abstraction layer - it simply deals with a json blob [01:36:08] and so does graph ext [01:36:13] there are good alternatives to string templating [01:36:58] gwicke, one thing at a time - i am willing to recondsider any approach, but at this point lets figure out how to migrate to the post storage first [01:37:19] (03CR) 10jenkins-bot: [V: 04-1] [WIP] Single edit tab [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/248369 (https://phabricator.wikimedia.org/T114530) (owner: 10Alex Monk) [01:37:44] gwicke, when do you think we can start playing with something? [01:38:00] yurik: the basic issues aren't resolved [01:38:15] and it would really be a lot better if you cleaned up this mess [01:38:49] gwicke, i am still failing to understand the mess - its a standard wiki markup, with an ability to expand template parameters inside the tag [01:39:10] it has been working flawlessly so far in PHP + graphoid world [01:39:12] we wouldn't spend on all these API end points, wouldn't start to store content that we can never delete, wouldn't need to tell clients like VE to do strange dances to get a preview etc [01:39:17] *time [01:39:22] i understand there are problems with ve/parsoid, so i'm trying to understand it [01:40:04] gwicke, but how is parameter expansion inside the differes from outside of it?? [01:40:14] its a regular templating language [01:40:23] right, a mess [01:40:44] ok, but its a much bigger mess than just a specific tag, right? [01:41:09] this one is the only one that seems to be really bad [01:41:31] here's the thing: a graph template, something that pretty much everyone wants, would have a "width": {{{width}}} parameter --- how do you propose to change it? [01:42:01] the only other approach i have seen is if Lua generates a giant sttring and returns it [01:42:03] [01:42:15] basically, define some sane interfaces [01:42:26] gwicke, doesn't work - simply because there are thousands of GRAPH-specific parameters [01:42:40] each graph designer is building their own graph "function" [01:42:51] so they are the ones defining which parameters to have [01:42:52] perhaps even [01:43:00] not solving it [01:43:16] because you want a graph to have any graph-defined parameters [01:44:18] so i take the "width" example back - not very good for this discussion. Instead, it could be "lineColor3" param - for a graph that has 5 lines, and offers a way to customize that one line [01:45:04] have a spec & edit that? [01:45:15] what do you mean by have a spec here? [01:45:23] yurik, this is why vega-lite seems like such a good idea now, it would take a lot of pain out of directly-embedded graphs [01:45:59] and since they have smart parameters like "marktype", maybe it can remove the need for templates? [01:46:10] ferdbold, vega lite & vega are not really that different - vega lite is simply a streamlined subset of vega [01:46:51] gwicke, ferdbold - https://en.wikipedia.org/wiki/Template:GraphChart [01:46:54] Anything which uses templates is probably going to kill VE supoprt for the foreseeable future. It took us years to get citation templates working - and that code is a hugh pile of hacks [01:47:08] if you wanted to go really ghetto, you could do , and then reference that by title / revision / id [01:47:30] gwicke, where would that uniqueid be defined? [01:47:38] in an attribute? [01:47:46] it only needs to be unique for the page [01:47:54] yurik: well, templates as they used right now don't strike me as very different from vega-lite: a streamlined syntax for vega [01:48:02] they are used* [01:48:28] ferdbold, lets discuss vega lite (which hasn't been released yet) separately, i agree its a great project, but will confuse everything here :)) [01:49:25] gwicke, if graph is produced by a template or lua code, you would still have to pass those ids all over the place - major pain [01:49:38] take a look at that template i showed -- it uses lua code to generate all these graphs [01:49:39] https://en.wikipedia.org/wiki/Template:GraphChart [01:50:02] this is how the majority of templates are done on all the wikis [01:50:23] simply because in the majority of the cases, ppl don't want to deal even with the graph design - they want a pre-set [01:50:40] you built a weird lua service with a badly designed api [01:50:56] gwicke, me? [01:51:13] weren't you involved in the graph extension development? [01:51:20] api - yes, my bad design, but lua is not my baby )) [01:52:51] gwicke, graph ext - yes, 95% mine, but what is that have to do with Lua? [01:53:45] your example there calls #invoke [01:54:32] gwicke, yes, because the actual graph is designed on the fly by lua module - which is exactly what lua is used for - for code-based content generation based on parameters [01:54:57] again, not my example - that's how ppl want to use graphs - have a template with parameters [01:55:17] and each community member can design their own graph templates [01:55:46] so is no different from any other template usage [01:55:56] those are all things that aren't unique to using Lua + textual templating [01:56:06] (03PS14) 10Alex Monk: [WIP] Single edit tab [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/248369 (https://phabricator.wikimedia.org/T114530) [01:56:38] so why is it a problem? i still fail to understand the fundamental issue -- why is it a problem for wiki markup to expand templates? [01:56:45] *template parameters [01:57:15] we were talking about graphoid [01:57:16] Krenair: Sorry, where? [01:57:26] James_F, https://people.wikimedia.org/~krenair/ve-tabs-pref.png [01:57:31] gwicke, we were talking about the graph ext in general [01:57:40] that's how it looks for me at the moment [01:57:56] Krenair: No drop-down? [01:58:10] hmm... yep, we could do that instead. good idea [01:58:45] Krenair: Kk. [01:58:47] I guess I kind of assumed radio buttons at some point and never questioned that, just grumbled about mediawiki not making it clear :p [01:58:49] Krenair: Language LGTM. [01:58:57] gwicke, with your example of approach, we would be strictly limited to a preset number of graphs that are designed by the developers. Just like music notes extension [01:59:02] Krenair: Maybe last-used editor? Eh. [01:59:13] yurik: are user-generated preset graphs an essential feature then? it seems like it's the major selling point for having templates, right? [01:59:32] is it such a problem? [01:59:55] yurik: you know, src=https://... can do magic [02:00:56] Still, at least it's as easy as changing 'radio' to 'select' [02:01:05] (03PS15) 10Alex Monk: [WIP] Single edit tab [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/248369 (https://phabricator.wikimedia.org/T114530) [02:01:06] ferdbold, user-generated graphs are just like user generated templates - we don't know what the community use cases are, and there are tons. So we give them a generic language to describe those graphs/maps. But generic language has to be flexible so that in each instance of a graph, it could use different params [02:01:23] gwicke, src=https:/ to where? what is the url? [02:01:27] (03PS2) 10Jforrester: WIP: Death to Cite code [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254082 [02:01:42] yurik: a data source, for example [02:01:57] somewhat similar to those image tags you might have seen before [02:03:19] yurik: having presets work as templates does mean they need to be deployed to every single wiki, each having different param names due to i18n, that seems dreadful [02:04:02] ferdbold, did you see https://meta.wikimedia.org/wiki/User:Yurik/I_Dream_of_Content ? [02:04:15] (03CR) 10jenkins-bot: [V: 04-1] WIP: Death to Cite code [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254082 (owner: 10Jforrester) [02:04:40] ferdbold, i started writing the steps to get there, and that is one of the main points -- https://meta.wikimedia.org/wiki/User:Yurik/From_Dream_to_Reality [02:06:09] like it or not, but the vast majority of wikipedia is heavily templated. And this is a good thing (TM) - it keeps it consistent and reduces duplication and the number of manual updates needed. So we should embrace it and think how to make it better in VE [02:06:20] (my opinion of course) [02:07:14] gwicke, unsure if it was a joke. The data source like CSV/JSON/API call/realtime data/image icons/... are all useful in a graph, and can be all used inside the vega [02:07:29] gwicke, http://vega.github.io/vega/vega-schema.json [02:07:43] full schema of vega2 - lots of different locations for things [02:09:53] http://vega.github.io/vega-editor/?mode=vega&spec=image [02:10:31] gwicke, ^ is a good example - you could have a graph that uses article-specific icons for things, like a logo of a company for stocks [02:11:29] great, then [02:12:35] so I guess we are in agreement that none of this absolutely requires wikitext templating [02:13:48] gwicke, how so? If someone writes a template "graph of stock performance", it would need parameters like several series of data, plus an icon file for each series [02:14:21] { graph_preset: 'stock', params: { ... } } [02:14:31] no templating [02:14:40] who writes the stock preset? [02:14:45] just a bit of json config [02:14:51] where is it stored? [02:15:07] i mean - it should be part of the wiki, right? [02:15:09] could be a namespace, where it can be fetched by some service [02:15:17] or something like restbase [02:17:10] that would absolutelly kill the idea - the graphs are powerful because they are so flexible - there could be tens of thousands of graphs. Leaving the issue of cross-wiki graph/template usage aside (big issue, separate discussion), each user should have a very simple way of modifying graph content just like they have a way of modifying templates [02:17:29] *thousand of graph templates [02:18:21] if i understand your proposal, you are saying that we should invent another templating language just for graphs [02:18:31] and store them separatelly [02:18:34] so have the presets all on some central wiki, let each user customize by passing in a config [02:19:02] & have a service that takes the config & preset & spits out JSON [02:19:30] there are plenty of object templating options around [02:19:30] i fully agree that we should unite wikis together, but again - you are proposing a new templating language just for graphs [02:19:40] re uniting -- https://meta.wikimedia.org/wiki/User:Yurik/From_Dream_to_Reality [02:19:44] first paragraph is about that [02:19:44] isn't that what commons is meant for? [02:19:47] if you wanted to make this a templating problem [02:20:12] gwicke, ferdbold, i think we should move it to commons - but not just graphs - all of templates too [02:20:19] and lua modules [02:20:52] according to James, commons doesn't have that capability yet since it's not media (i know nothing about commons) [02:20:57] but unless you are saying that we should throw away the existing templating language + lua language, I would prefer we don't invent another being [02:21:40] ferdbold, yep, we do not support cross-wiki transclusion - my huge pet peeve [02:21:41] this is assuming that you actually need one [02:22:01] gwicke, do you think we should get rid of templates? [02:22:28] for this use case, yes [02:22:43] well, but than you are saying that we should have multiple languages [02:22:54] using wikitext templating to construct JSON is gross on several levels [02:22:55] one for simple wiki markup, and one for each extension that expands a tag [02:23:24] gwicke, but is it ok to use Lua to construct json? [02:23:40] e.g. Lua constructs an internal data structure, and exports it to json? [02:24:54] yurik: I don't care too much, tbh [02:25:02] but its the same issue! [02:25:32] templates and lua are actually the same in a way [02:25:55] they both take params, and expand into content [02:28:13] yurik: you can say the same about writing everything in C macros [02:29:26] we are still talking about text, right? i'm not a big fan of the templating language we have - for a number of reasons. But I don't think we should introduce multiple templating systems [02:31:36] yurik: how about this: store preset specs somewhere like meta or commons, and then have the graph ext pull those specs from every wiki, and render graphs by combining the specs with user-defined edits [02:32:32] so that each 's data is actually just a reference with the preset and a list of diffs to apply [02:33:11] ferdbold, but when you say "graph ext will combine", you imply that it has its own combining language. Plus, we really should not try to solve common cross-wiki usage with a custom solution like this [02:33:45] just like we use images everywhere from commons, we should use templates and lua modules from "code commons" [02:33:58] yurik, that's the way I'm doing it inside the graph-ve module when I apply edits to a spec: just extend the serialized JSON objects with new properties [02:34:02] yurik: No. [02:34:28] James_F, you think we should not have a common template & lua repository? [02:35:34] yurik: I think that we will not be working on it in the next year or two. [02:35:53] yurik: We'll be doing encapsulation and Scribunto/JS first. [02:36:09] James_F, you mean common lua repo? [02:36:18] yurik: No. :-) [02:36:31] so what do you mean by scribunto/js first? [02:36:31] Scribunto/JS as an alternative/replacement to Scribunto/Lua. [02:37:19] what's the point??? Lua is not ideal, but what is the major advantage of switching if we could instead build a common repo and provide immediate benefit?? [02:37:33] It's a dead end. [02:37:38] We already have on-wiki JS. [02:37:42] Also, this is not the venue. [02:38:23] dead end to provide a common code/template/data repository? [02:38:44] 10VisualEditor, 10Graph-VisualEditor, 5WMF-deploy-2015-12-01_(1.27.0-wmf.8): Edit graph size in VisualEditor - https://phabricator.wikimedia.org/T109631#1816202 (10Jdforrester-WMF) 5Open>3Resolved [02:47:34] 10Cite, 10VisualEditor, 6Editing-Department, 6Parsing-Team: Use ext.cite.style to style output, rather than wikitext styling - https://phabricator.wikimedia.org/T104927#1816225 (10Jdforrester-WMF) [02:47:37] 10Cite, 10VisualEditor, 10VisualEditor-MediaWiki, 10VisualEditor-MediaWiki-References, and 4 others: Move ext.visualEditor.mwreference registration back to extension.json once ext.cite.style is definitely available - https://phabricator.wikimedia.org/T104928#1816224 (10Jdforrester-WMF) [02:50:07] James_F, so i am not very clear about the overall future direction - was it discussed? Even though i think it would be awesome to have JavaScript instead of lua, i don't see any real benefit to the community. Whereas if we concentrate on cross-site resource sharing, we could immediately unite wikis [02:50:23] would love to see your vision though, please write [02:51:27] 10VisualEditor, 7Technical-Debt: Remove use of ve.indexOf - https://phabricator.wikimedia.org/T89905#1816240 (10Jdforrester-WMF) Done in Ib6aca26b. [02:52:01] 10VisualEditor, 7Technical-Debt: Remove use of ve.indexOf - https://phabricator.wikimedia.org/T89905#1816241 (10Jdforrester-WMF) 5Open>3Resolved a:3Jdforrester-WMF [03:18:07] (03PS1) 10Tchanders: Make selectRange method of AceEditorWidget focus the input [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254092 [03:19:17] (03CR) 10Catrope: [C: 032] Make selectRange method of AceEditorWidget focus the input [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254092 (owner: 10Tchanders) [03:28:45] (03Merged) 10jenkins-bot: Make selectRange method of AceEditorWidget focus the input [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254092 (owner: 10Tchanders) [03:28:49] [16:36:04] do it with your volunteer account, everyone knows you're an entirely different person when using it rather than the WMF one! <-- it's true https://meta.wikimedia.org/wiki/User:MarkTraceur/Essays/WMF_usernames [03:38:43] 10VisualEditor, 10Graph-VisualEditor: Graph does not appear in Read mode after saving the page - https://phabricator.wikimedia.org/T118896#1816269 (10ferdbold) Update: This is due to a clash between assumptions that VE and the Graph extension makes on how data is fetched from. On a save from VE, the HTML prese... [04:14:21] 10VisualEditor, 10Math, 5Patch-For-Review: Let users click on a list of all the formula fragments to insert them - https://phabricator.wikimedia.org/T114163#1816314 (10Jdforrester-WMF) [04:14:24] 10VisualEditor, 10Math: Provide (1) a script to generate the SVG and CSS files needed for the formula list, and (2) the generated files - https://phabricator.wikimedia.org/T118660#1816310 (10Jdforrester-WMF) 5Open>3Resolved [07:16:27] (03PS1) 10Esanders: AceEditorWidget: Ensure loadingPromise is set when setupEditor runs [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254110 [08:48:36] 10VisualEditor, 10VisualEditor-MediaWiki, 5WMF-deploy-2015-11-10_(1.27.0-wmf.6): Switching from a WT section edit to VE only switches with the wikitext of the section, not the article - https://phabricator.wikimedia.org/T117713#1816507 (10TheDJ) What if you'd din't make a change in your section yet ? https:... [12:05:22] 10VisualEditor, 10Math: Fix empty math editing box for users of MathML rendering mode - https://phabricator.wikimedia.org/T118435#1816793 (10Physikerwelt) You can try yourself on http://math.beta.wmflabs.org:8080/wiki/VisualEdit?veaction=edit [14:31:43] 10VisualEditor: Template: Input for template name always marked as invalid, even if template exist - https://phabricator.wikimedia.org/T119075#1817090 (10Florian) 3NEW [16:01:43] Krenair: dropdown rather than radio buttons for that pref, please :) [16:07:11] (03CR) 10Bartosz Dziewoński: [C: 04-1] "Does not merge, needs manual rebase." [extensions/WikiEditor] - 10https://gerrit.wikimedia.org/r/253282 (owner: 10Paladox) [16:26:26] 10VisualEditor, 6Collaboration-Team-Backlog, 6Community-Tech, 10Flow, and 4 others: Parsing team: Q3 2015-16 goals planning dependency tracker task - https://phabricator.wikimedia.org/T119088#1817460 (10Arrbee) [16:44:07] (03CR) 10Jforrester: [C: 032] AceEditorWidget: Ensure loadingPromise is set when setupEditor runs [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254110 (owner: 10Esanders) [16:47:15] (03Merged) 10jenkins-bot: AceEditorWidget: Ensure loadingPromise is set when setupEditor runs [extensions/VisualEditor] - 10https://gerrit.wikimedia.org/r/254110 (owner: 10Esanders) [17:28:50] Elitre, yes, I did that [17:29:19] Krenair: of course you did. tnx! [17:47:35] 10VisualEditor, 10OOjs-UI: Template: Input for template name always marked as invalid, even if template exist - https://phabricator.wikimedia.org/T119075#1817747 (10Florian) Adding #oojs-ui, it seems to be a problem with the latest release, because I see this on Special:MovePage, too. For the new title input,... [17:57:27] gwicke, ferdbold, thx for yesterdays brainstorming. Gabriel, some basic thoughts about JSON builder - https://phabricator.wikimedia.org/T119050 [17:57:31] But more importantly - https://phabricator.wikimedia.org/T119043 [17:57:46] that discusses how we can implement graph storage in general [18:09:51] Hallo. [18:10:04] There are a bunch of new messages to translate about Math. [18:10:24] Derivatives, Functions, Geometry, Modular, etc. [18:10:30] Can I see a demo of that anywhere? [18:14:49] mooeypoo ryasmeen James_F ^ [18:23:46] ferdbold, i think i will implement an easy api to get graph spec, and in the mean time you can already get graph spec from https://www.mediawiki.org/w/api.php?action=query&prop=pageprops&titles=Extension:Graph/Demo [18:25:05] yurik: awesome, thank you :) [18:27:02] ferdbold, yw. pls comment on https://phabricator.wikimedia.org/T119043 [18:35:32] aharoni: https://gerrit.wikimedia.org/r/#/c/253374/ is the code, but it's not fully working yet. [18:44:28] mooeypoo, James_F: I wonder what exactly does "Modular" mean and how to translate it. [18:51:56] 10VisualEditor, 10Score: Provide better error message when a Score is empty - https://phabricator.wikimedia.org/T116392#1818088 (10Esanders) p:5High>3Low [18:52:20] aharoni, In what context? [18:52:41] mooeypoo: VisualEditor Math. [18:52:52] Like modulus? [18:52:56] I can understand what the rest of the labels are. [18:53:04] Maybe, but I'm not sure. [18:53:41] There's modular math, but I have no clue how to say that n Hebrew [18:53:43] let me search [18:54:00] The messages are math-visualeditor-symbol-group-* [18:54:04] https://he.wikipedia.org/wiki/%D7%97%D7%A9%D7%91%D7%95%D7%9F_%D7%9E%D7%95%D7%93%D7%95%D7%9C%D7%A8%D7%99 [18:54:06] aharoni, ^^ [18:54:15] seems it's also called "modular" without translation? [18:54:51] מודולרי [18:54:56] looks approproate [18:55:00] seems so, yeah [18:55:11] though it's not really translated. Transliterated, mostly. [18:55:18] good enough [18:55:33] Yeah it looks like the official term for it [18:55:43] somewhat surprisingly, the Academy of Hebrew didn't even bother to invent a Hebrew term for "Operator" [18:55:58] ... I never even realized that [18:56:00] ha [18:56:12] * guillom likes seeing non-latin characters in his IRC. [18:56:12] wait, what is it in hebrew? אופרטור? ? [18:56:35] Yes, אופרטור [18:56:43] I updated the qqq: https://translatewiki.net/wiki/MediaWiki:Math-visualeditor-symbol-group-modular/qqq [18:56:51] Thank you [18:59:31] ... aaaaand thanks to mooeypoo the translation of messages for MediaWiki Extensions Used by WikiMedia is back at 100% and I can go to sleep peacefully * https://translatewiki.net/w/i.php?title=Special:MessageGroupStats&group=ext-0-wikimedia#sortable:3=desc [18:59:44] guillom: there are 9 untranslated to French [19:00:02] * guillom clicks. [19:00:55] 10VisualEditor, 10VisualEditor-MediaWiki-Mobile, 10MobileFrontend, 7Technical-Debt, 7Tracking: [EPIC] Move VisualEditor code from MobileFrontend to VisualEditor - https://phabricator.wikimedia.org/T96186#1818126 (10Jdforrester-WMF) a:5Esanders>3None [19:01:52] 10VisualEditor, 10VisualEditor-ContentEditable, 7Technical-Debt: Break up ve.ce.Surface.js by functionality - https://phabricator.wikimedia.org/T78696#1818133 (10Jdforrester-WMF) [19:01:54] 10VisualEditor, 10VisualEditor-ContentEditable, 7Technical-Debt, 5WMF-deploy-2015-12-01_(1.27.0-wmf.8): Abstract getSelectionRects by selection type - https://phabricator.wikimedia.org/T118798#1818130 (10Jdforrester-WMF) 5Open>3Resolved [19:02:19] yurik: Any way I can trigger graphoid to render a new spec from the front-end? That API link is dandy but mediawiki.org only serves graphoid images… so there's no way I can display new graphs unless graphoid serves them [19:03:18] ferdbold, when you ask graphoid to render an image, you have to give it a hash. That hash has to exist in mediawiki sql. If you give a wrong sql, you won't get an image [19:03:24] 10VisualEditor, 6Collaboration-Team-Backlog, 6Community-Tech, 10Flow, and 4 others: Parsing team: Q3 2015-16 goals planning dependency tracker task - https://phabricator.wikimedia.org/T119088#1818145 (10GWicke) Some things that I'd love to see prioritized on your end are: - Improve how Parsoid marks up se... [19:04:00] 10VisualEditor, 10VisualEditor-ContentEditable: When a link is the first element on a page, don't launch the link context menu automatically; instead put the cursor in the placement outside the link - https://phabricator.wikimedia.org/T114376#1818152 (10Jdforrester-WMF) a:5dchan>3None [19:04:00] ferdbold, there is no concept of "re-render", simply because the same hash usually gerates the same graph [19:04:14] but that hash must exist as one of the page props [19:04:41] ferdbold, that api call basically gets you the spec, the same way graphoid does it [19:04:44] https://en.wikipedia.org/wiki/Special:PagesWithProp?propname=graph_specs&propname-other= [19:05:11] ^ shows what is stored at the moment in the pageprops, same as the api [19:05:59] yurik: I'm not sure these get refreshed on a VE save, or even if Graphoid gets notified about them if VE changes them [19:06:16] 10VisualEditor, 10VisualEditor-ContentEditable: When backspacing away the last character in a list item, a
is added - https://phabricator.wikimedia.org/T94483#1818155 (10Jdforrester-WMF) a:5dchan>3None [19:06:20] 10VisualEditor, 10VisualEditor-MediaWiki-Mobile, 7Browser-Support-Google-Chrome: VisualEditor Mobile: Chrome for mobile keyboard doesn't fire useful key events for backspace - https://phabricator.wikimedia.org/T69262#1818156 (10Jdforrester-WMF) a:5dchan>3None [19:06:24] 10VisualEditor, 10VisualEditor-ContentEditable: Backspace/delete can remove unpaired unicorn images - https://phabricator.wikimedia.org/T90540#1818157 (10Jdforrester-WMF) a:5dchan>3None [19:06:40] ferdbold, graphoid is never notified about anything. You give it a hash. It calls api for that page, and looks for the hash. If it finds it, it will give you the image [19:07:34] yurik: so what "calls" graphoid in the first place? parsoid? [19:07:45] ferdbold, your browser does [19:07:56] mediawiki generates HTML with a URL [19:08:08] that URL contains page title, revid (or 0), and a hash [19:08:41] that URL tells graphoid all it needs to know to call the api on your behalf [19:08:50] and get the spec from SQL [19:08:54] you're talking about stuff like , correct? [19:08:59] yes [19:09:09] this is a graphoid endpoint [19:10:17] ferdbold, so from that link, it looks at the sandbox page via Mediawiki api [19:10:31] ferdbold: so if this URL changes to a new spec after a VE save, and pageprops are updated to include this hash, graphoid should be able to render a new graph based on that new spec, correct? [19:10:41] URL changes to a new hash* [19:10:42] talking to yourself? ) [19:10:48] oops haha [19:11:01] yep [19:11:06] (mornings) [19:11:40] 10VisualEditor, 10VisualEditor-ContentEditable: Able to insert new lines after the cursor (? due to being on the wrong side of a nail) - https://phabricator.wikimedia.org/T118876#1818183 (10Jdforrester-WMF) a:5dchan>3None [19:11:47] 10VisualEditor, 10VisualEditor-ContentEditable, 10VisualEditor-Links, 10VisualEditor-MediaWiki-Links: Model and view out of sync when link deleted and replaced with text - https://phabricator.wikimedia.org/T115001#1818184 (10Jdforrester-WMF) a:5dchan>3None [19:12:00] ferdbold, of course there could be the case when pageprops table have been updated on the master with the new graph spec (under the new hash), but the slaves haven't synced up yet [19:12:54] so graphoid would get the older spec for that page when you call it right away, and thus fail [19:13:33] but this is mysql database replication issue [19:13:44] which is fairly hard to solve [19:13:54] if that's what happens [19:14:28] you could re-request the same image if it fails right after save [19:21:11] 10VisualEditor, 10VisualEditor-MediaWiki-Mobile, 7Design: VisualEditor Mobile: Allow formatting editing - https://phabricator.wikimedia.org/T67586#1818226 (10Jdforrester-WMF) p:5High>3Low [19:21:17] 10VisualEditor, 10VisualEditor-MediaWiki-Mobile, 7Design: Fix the jump when opening the mobile context - https://phabricator.wikimedia.org/T96289#1818227 (10Jdforrester-WMF) p:5High>3Normal [19:22:43] 10VisualEditor, 10VisualEditor-MediaWiki-Mobile: [Regression ?] Newline is appearing before every listed item in mobile VE - https://phabricator.wikimedia.org/T114716#1818229 (10Jdforrester-WMF) p:5High>3Low [19:22:51] 10VisualEditor, 10VisualEditor-MediaWiki-Mobile: [Regression ?] Newline is appearing before every listed item in mobile VE - https://phabricator.wikimedia.org/T114716#1818230 (10Jdforrester-WMF) 5Open>3stalled [19:23:07] edsanders: CR on https://gerrit.wikimedia.org/r/#/c/252592/ please? [19:24:28] 10VisualEditor, 10Phlogiston, 15User-JAufrecht: Filter VE report by task priority - https://phabricator.wikimedia.org/T119107#1818238 (10JAufrecht) a:3JAufrecht [19:25:55] 10VisualEditor: [Regression wmf20] Media search is not returning any result unless there is a change in the search term by typing or deleting something inside the search box - https://phabricator.wikimedia.org/T110570#1818241 (10Jdforrester-WMF) 5Open>3Resolved a:3Jdforrester-WMF Closing as WFM. [19:28:55] 10VisualEditor, 10VisualEditor-CopyPaste: 'Uncaught TypeError: Cannot read property 'start' of null' when pasting Categories in VE - https://phabricator.wikimedia.org/T115273#1818254 (10Jdforrester-WMF) [19:28:56] 10VisualEditor, 10VisualEditor-MediaWiki, 5WMF-deploy-2015-12-01_(1.27.0-wmf.8): Pasting the wikitext to instantiate a category link into VE throws a fatal - https://phabricator.wikimedia.org/T118191#1818255 (10Jdforrester-WMF) [19:34:24] 10VisualEditor, 10VisualEditor-CopyPaste, 7Browser-Support-Firefox: Pasting into a VE surface in Firefox adds spurious line breaks and nowikis - https://phabricator.wikimedia.org/T104790#1818290 (10Jdforrester-WMF) I remain unable to replicate with wmf.5 or later. Can you re-test? [19:34:53] 10VisualEditor, 10Parsoid, 10RESTBase: RESTBase doesn't purge renamed page -> VisualEditor unable to create moved page - https://phabricator.wikimedia.org/T110152#1818292 (10Jdforrester-WMF) [19:35:43] 10VisualEditor, 10VisualEditor-MediaWiki-Mobile: Detect annotation changes on poll - https://phabricator.wikimedia.org/T114751#1818293 (10Jdforrester-WMF) a:5dchan>3None [19:35:52] 10VisualEditor, 10VisualEditor-ContentEditable: DM/DOM sync errors can arise from spellchecking in Firefox - https://phabricator.wikimedia.org/T116273#1818295 (10Jdforrester-WMF) a:5dchan>3None [19:36:03] 10VisualEditor, 10VisualEditor-ContentEditable, 7Epic: DM/DOM sync can break if you use an IME - https://phabricator.wikimedia.org/T116275#1818296 (10Jdforrester-WMF) p:5Normal>3High [19:36:11] 10VisualEditor, 10VisualEditor-MediaWiki: Cursoring jumps over entire link - https://phabricator.wikimedia.org/T118644#1818297 (10Jdforrester-WMF) a:5dchan>3None [19:36:56] 10VisualEditor, 10VisualEditor-Performance, 7Epic, 5Patch-For-Review, and 2 others: Internal nodes should eventually be in a separate document ("sub-documents") - https://phabricator.wikimedia.org/T49344#1818298 (10Jdforrester-WMF) p:5Normal>3High [19:39:03] 10VisualEditor, 10VisualEditor-MediaWiki: The two edit tabs have different tool tips set in code but they are showing the same one - https://phabricator.wikimedia.org/T119110#1818307 (10Jdforrester-WMF) 3NEW [19:39:08] 10VisualEditor, 10VisualEditor-MediaWiki: The two edit tabs have different tool tips set in code but they are showing the same one - https://phabricator.wikimedia.org/T119110#1818316 (10Jdforrester-WMF) [19:39:28] 10VisualEditor, 10WikiEditor, 6Design Research Backlog, 7Easy, and 2 others: Tooltip text on the "Edit" and "Edit Source" tabs should be more helpful to new users - https://phabricator.wikimedia.org/T99271#1818323 (10Jdforrester-WMF) 5Open>3Resolved Moved that to T119110. [19:41:28] 10VisualEditor, 10Parsoid: VE add images with "link=" pointing to the image - https://phabricator.wikimedia.org/T116463#1818336 (10Jdforrester-WMF) [19:41:31] 10VisualEditor, 10VisualEditor-MediaWiki-Media, 10Parsoid, 5Patch-For-Review: Parsoid/VE adds images with pointless link parameter - https://phabricator.wikimedia.org/T108504#1818337 (10Jdforrester-WMF) [19:42:36] 10VisualEditor, 10Graph-VisualEditor, 10OOjs-UI: Bottom paddings visual issue - https://phabricator.wikimedia.org/T119017#1818342 (10Jdforrester-WMF) p:5Triage>3Normal a:3ferdbold [19:53:33] 10VisualEditor, 10VisualEditor-DataModel, 7Browser-Support-Google-Chrome: When backspacing over images that are off screen, scroll down to the images (Chrome) - https://phabricator.wikimedia.org/T110700#1818360 (10Jdforrester-WMF) p:5High>3Normal [20:15:02] 10VisualEditor, 10OOjs-UI: Template: Input for template name always marked as invalid, even if template exist - https://phabricator.wikimedia.org/T119075#1818423 (10Krenair) Looks like the validation function isn't being set up properly [20:17:10] 10VisualEditor, 6Collaboration-Team-Backlog, 6Community-Tech, 10Flow, and 4 others: Parsing team: Q3 2015-16 goals planning dependency tracker task - https://phabricator.wikimedia.org/T119088#1818427 (10ssastry) >>! In T119088#1818145, @GWicke wrote: > - Multimedia support, even if it's "just"