[02:03:03] (03PS6) 10Catrope: Fix ContentBranchNode echo suppression at the ends of text nodes [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/118792 [02:04:18] (03CR) 10Jforrester: "PS6 is an in-gerrit-rebase-via-the-cherry-pick-to-button-aimed-at-master, because gerrit sucks." [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/118792 (owner: 10Catrope) [04:19:42] hi [04:20:42] after seeing the talk on visual editor at LCA2014, i believe you can set up visual editor to not require parsoid and save as html? how do i configure that? [06:39:45] k-man: They may have spoken about that as a hypothetical, in the future [06:39:51] I don't think they've built any of that yet [06:40:08] k-man: https://www.mediawiki.org/wiki/User:GWicke/Notes/Storage [07:08:03] ah ok, tahnks rdwrer [09:11:33] Hello need some help to start with visual editor plugins gsoc idea [09:11:46] Anyone there to help? [09:57:35] santosh2201: The Visual Editor team is in SF so they're usually not around until 9am UTC-8. So in about 6 hours. [10:10:06] Thanks then i will get back in 6 hours [13:57:52] (03PS1) 10Esanders: Don't try to return the document in getCoveredNodes [VisualEditor/VisualEditor] - 10https://gerrit.wikimedia.org/r/119045 [14:38:43] Heya all. [14:41:34] Hi [14:44:17] James_F, on https://bugzilla.wikimedia.org/show_bug.cgi?id=52004#c3 I had said that I didn't think this should be done through the existing paction=parse API [14:44:29] however I looked into other stuff that it sends and decided I'd add to that [14:45:06] OK… [14:49:32] James_F, anyway I did it, and for testing showed it like this: https://dl.dropboxusercontent.com/u/10971457/Wikimedia/VisualEditor/Blocked%20text%20WIP.png [14:50:47] * James_F nods. [14:51:16] We're probably going to need to widen the page/edit notices panel, I guess. [14:51:37] You want to put that in the edit notices panel? [14:52:39] Yeah... I don't think that message was created with a small edit notices box in mind. English Wikipedia's custom one is worse: http://bug-attachment.wikimedia.org/attachment.cgi?id=12954 [14:53:30] Krenair: Do you think they're aware that banners like that don't work? [14:54:22] Sorry, don't work? Do you mean that people try to edit anyway? [14:54:28] (Full width top banners get lumped into the same category as adverts, and most people don't even see them.) [14:55:19] Also the WT editor is made read-only by this error. Not sure how this should be done in VE... [14:55:36] We can disable the save button. [14:56:20] WT editor makes the textarea readonly, I don't particularly like that [14:56:26] Indeed. [14:56:33] WT editor sucks: News at 11. ;-) [14:56:38] So was going to suggest just disabling the save button too [14:57:00] * James_F nods. [14:59:29] James_F, hm, it's not as bad as I was expecting: https://dl.dropboxusercontent.com/u/10971457/Wikimedia/VisualEditor/Blocked%20text%20edit%20notice%20WIP.png [15:00:20] Krenair: Yeah, built-in messages should generally be fine. [15:00:27] Krenair: It's the locally-customised ones that suck. [15:06:54] James_F, am wondering whether to leave it outside the VE area or make the box bigger [15:08:42] Krenair: Make the box bigger. Nothing should go outside VE. :-) [15:29:44] James_F, enwiki's autoblocked message is even worse [15:30:06] Krenair: Shocked, shocked I am. [15:39:31] James_F, made the edit box bigger than my screen, still not big enough to show everything unless I add a scroll bar [15:40:18] (kind of) [15:40:35] Hey all, I'd like to push my branch to merge but I'm a little confused by the organization of the git repos. If I pull /mediawiki/extensions/VisualEditor, VisualEditor/lib/ve is empty and I need that for testing, but I notice that that's where most of the commits are going? [15:41:15] But some commits are being made in VisualEditor/VisualEditor on gerrit too [15:41:33] Hi mvolz [15:41:35] mvolz: You need to do `git submodule --init` on first checkout, and later `git submodule update` [15:41:42] You need to git submodule update --init [15:41:45] Aha [15:41:47] Thanks! [15:41:56] (this is on https://www.mediawiki.org/wiki/Extension:VisualEditor ) [16:15:47] So it looks like oojs-ui in the library isn't tracked? [16:16:26] mvolz: It's pulled in as a build. [16:16:39] mvolz: That's in https://git.wikimedia.org/summary/oojs%2Fui.git [16:17:19] Ok. [16:18:04] Actually, the MW version of VE has OOjs UI loaded from MW itself. [16:31:55] James_F, your rename of https://bugzilla.wikimedia.org/show_bug.cgi?id=62728 suggests you know something I don't [16:39:11] edsanders: Thought-o, sorry. [16:39:25] edsanders: {{fixed}} [16:59:17] Is hangouts down? "Things are taking longer than expected. [16:59:19] " over here [16:59:31] James_F, hey, is there a hangout today? [16:59:57] hm, yep. just ran into the same issue. I assume not then [17:00:15] :( There is a problem connecting to this video call. Try again in a few minutes. [17:01:53] Same here [17:01:56] http://www.google.com/appsstatus#hl=en&v=status [17:02:15] Products not covered by Google Apps Service Level Agreement: [17:02:16] Hangouts [17:02:37] Yeah mobile team is not able to connect either [17:02:49] 40 minutes ago :/ [17:03:52] it seems hangouts on my phone is working about 50% [17:04:32] Nice, meeting moved to 11 [17:04:36] Thanks James_F [17:05:34] 11 AM SF time? [17:05:55] So that's in 55 minutes [17:05:58] In 55 minutes [17:13:40] Krenair: Yeah. [17:30:09] James_F: Hey been a while since i've looked at my worklist. Currently working on the last item. Want to give a hand prioritizing stuff ? [17:30:54] rmoen: Sure! [17:31:23] James_F: ty [17:31:29] mooeypoo: you're still working on VE and images, right? could you help me debug https://bugzilla.wikimedia.org/show_bug.cgi?id=49844 ? [17:34:41] cscott, sure thing [17:35:07] mooeypoo: in particular, i'm interested in what HTML VE generates for new links to images from commons. [17:35:17] cscott, I didn't see this bug in action though [17:35:26] let me verify [17:35:37] mooeypoo: auto-commons might also play a role, this might happen if the new image appears to be local but is actually an auto-commons image. [17:36:04] right, I was going to see if I see a difference when I turn auto commons off [17:36:10] thanks [17:39:05] Hi everyone [17:39:36] I have a doubt regarding visual editor gsoc idea [17:39:41] rmoen: Anything in https://bugzilla.wikimedia.org/buglist.cgi?bug_severity=enhancement&bug_status=ASSIGNED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Ccomponent%2Cshort_desc%2Ctarget_milestone&component=Editing%20Tools&component=Initialisation&component=MediaWiki%20integration&email1=jforrester%2Bveteambztickets%40wikimedia.org&emailassigned_to1=1&emailtype1= [17:39:41] substring&known_name=VE-%2A-enhance&list_id=287971&product=VisualEditor&query_based_on=VE-%2A-enhance&query_format=advanced&resolution=--- take your fancy? [17:40:03] Can i discuss about it here? [17:40:12] santosh2201: Heya. [17:40:55] santosh2201: Yes, of course. [17:41:37] rmoen: https://bugzilla.wikimedia.org/buglist.cgi?bug_severity=enhancement&bug_status=ASSIGNED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Ccomponent%2Cshort_desc%2Ctarget_milestone&component=Editing%20Tools&component=Initialisation&component=MediaWiki%20integration&email1=jforrester%2Bveteambztickets%40wikimedia.org&emailassigned_to1=1&emailtype1=substring&pr [17:41:38] oduct=VisualEditor&query_format=advanced even. [17:41:38] In visualeditor plugin idea what plugins are you expecting [17:41:46] Bah, still too long. [17:42:34] santosh2201: VisualEditor lets you write normal content, and some "generated" content – references, templates, images, etc. – but there's loads of generated content types that you can't edit in VisualEditor yet. [17:43:05] Is easytimeline plugin enough or poems,score should also be implemented [17:43:10] cscott, so, with $wgUseInstantCommons=true, I just get [[File:Diplopedia main page.jpg|thumb]] (image is from commons) and with it =false, i get only local images, and when I insert one of those, I get the same wikitext. [17:43:15] santosh2201: The idea is that if you have an extension or type of tag you really like, you might want to build a VisualEditor plugin for that extension/type. [17:43:45] santosh2201: would be very basic, I think; could be interesting. [17:43:51] hm. does VE allow you to manually specify the URL, pointing at a commons image? [17:44:08] cscott: No. [17:44:17] cscott: Search only right now. [17:44:33] cscott, not yet [17:44:35] cscott: But you can input the name of the image from Commons. [17:44:45] if you have instant commons [17:44:49] Would that cause http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=81525&oldid=81245 ? [17:46:19] cscott, I can't manage to replicate this, though. It's odd. If you have the option of adding an image from commons, it seems to be added without link= because instant commons is on, and if you don't have it on, there's no option rigth now to add an image from commons (or a link= at all for that matter) [17:46:27] on the parsoid side, i am seeing that we don't do full interwiki processing on the 'figure img[resource]' and 'figure a[href]' attributes, so it's possible that links to commons files might not be picked up as such. [17:47:03] but we certainly do suppress the link= attribute if img[resource] == a[href]. so the presence of a link= attribute means that something weird is happening on the VE side. [17:47:30] mooeypoo, FWIW I moved my Wiki to /wiki and the media dialog is now submitting searches to the API [17:47:41] mooeypoo: what if you add from instant commons, then try to manually edit the link? [17:48:31] RobertLabrie: Aha, good. [17:49:00] James_F, the API isn't returning any results, but that's between me and MW search now, so at least you're off the hook :) [17:49:10] RobertLabrie, woot, great! [17:49:17] mooeypoo: i'm going to try to recreate http://en.wikipedia.beta.wmflabs.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox&diff=81525&oldid=81245 exactly; ie, add a thumbnail of File:Sandbox 1.JPG to a sandbox page on en.wikipedia.beta.wmflabs.org. [17:49:39] cscott, you can't edit the link right now in VE [17:50:04] oh, sorry, you mean in wikitext? [17:50:36] mooeypoo: i don't know. i'm trying to figure out exactly what Whatamidoing was doing. ;) [17:51:24] incidentally, does en.wikipedia.beta.wmflabs.org share login accounts with enwiki or anything else? it looks like a need to create a new account there? [17:51:45] cscott: No auth is shared, no [17:51:51] Presumably for security reasons [18:00:56] Bump standup again? [18:01:00] James_F: [18:02:54] mooeypoo, James_F: i can't seem to reproduce this either. [18:03:15] do we know who Whatamidoing is? [18:05:47] cscott: Yess [18:05:57] She's one of WMF's community liaisons [18:06:48] any chance there was a beta or buggy version of VE on 27 feb 2014? [18:07:10] i guess the larger question is: do we plan to allow adding images on external wikis *other than via instacommons*. [18:07:14] rmoen: Yeah. [18:07:29] cscott: Define "external wiki" [18:07:30] cscott: It was reproducible in production too, sadly. [18:07:33] cscott: No. [18:07:59] for instacommons we use local links for the File: and the commons redirect happens magically. the question is, do I have to parse a full URL in the resource attribute and figure out that it's a interwiki link of some kind. [18:08:20] cscott: There is no such thing as interwiki images [18:08:26] there's a mediawiki option to allow direct image links to external sites [18:08:31] But the wiki can configure multiple $wgForeignFileRepos [18:08:41] right, that too. [18:08:54] for $wgForeignFileRepos, the resource URL is still local, though. [18:08:58] Those will all work with [[File:]] syntax though, same as InstantCommons [18:09:02] yeah. [18:09:48] so what i'm saying is, i think parsoid is doing the entirely correct thing. it suppresses the link= option if a[href] == img[resource], and it doesn't do any super-fancy processing on a[href]/img[resource], but that's okay since media links should always be local. [18:10:29] (except for $wgAllowExternalImages, but we don't really support that) [18:11:51] Yeah screw $wgAllowExternalImages for now as far as I'm concerned [18:15:07] ok, well I messaged whatami (https://en.wikipedia.org/wiki/User_talk:Whatamidoing_%28WMF%29#VE_bug_49844) to ask for more details [18:15:22] but at the moment i'm feeling like we should reclose https://bugzilla.wikimedia.org/show_bug.cgi?id=49844 [18:16:20] and that parsoid is correct in not trying to look for interwiki links in URLs within

. VE should be giving parsoid local urls. [18:16:35] Hi cscott. I didn't do anything strange at all: I added a plain old image with a boring caption and some simple alt text, and it added the link. [18:17:15] whatami: yeah, i tried to do exactly the same thing at http://en.wikipedia.beta.wmflabs.org/wiki/User:Cscott/Sandbox1 just now, and couldn't reproduce. [18:17:23] mooeypoo tried additional variations [18:17:52] so i think the bug is fixed? (even though we don't know exactly what broke it) [18:18:02] I can't either, any longer. James told me very shortly after I filed the bug that he knew what was wrong and would get it handled. [18:18:21] James_F you sneaky devil [18:18:32] by "get it handled" i think he meant "assign the bug to me" ;) [18:18:49] If memory serves, it was handled in VisualEditor, then it was supposed to be fixed in Parsoid, so they turned off the VisualEditor hack, except that it wasn't actually handled in Parsoid, so it had to be turned on again. [18:18:59] But memory may not serve. ;-) [18:19:11] That does sound like something we did, yes [18:19:15] cscott: No, no, we "handled" it by reverting the hack in VE and pushing out an emergency live patch. [18:19:24] oh, did you turn on the workaround again? ah. [18:19:27] cscott: The longer-term bug remains. [18:19:38] can you point me to the workaround patch? [18:19:48] if img[resource] != a[href] i think that's a VE bug. [18:19:50] So it's still broken, but you can't see the breakage. [18:22:15] James_F, mooeypoo: so https://gerrit.wikimedia.org/r/#/c/114352/3/modules/ve-mw/ui/dialogs/ve.ui.MWMediaInsertDialog.js is what we're talking about, i guess. [18:23:08] cscott: Yes, and then that revert got reverted again [18:23:16] "Set href attribute..." was a workaround from last year [18:23:19] i think that workaround is 'correct', since ('./' + this.item.title) should either be idential to info.descriptionurl or redirect to it. is there some other case that i'm not seeing? [18:23:34] For whatever reason we believed it was no longer needed, so we reverted it [18:23:41] Then it broke, so we reverted the revert [18:23:47] What you're looking at is number 2 of those 3 [18:23:53] i.e. the wrong one [18:24:13] yeah, sure. but i'm trying to understand why you think that info.descriptionurl is the 'right' url for the link. [18:24:35] James_F: Why is https://bugzilla.wikimedia.org/show_bug.cgi?id=61560 still open? Didn't we do the Revert "Revert "..."" thing? [18:24:37] in the current code, we have that line commented out and the href: './' + this.item.title in there instead [18:24:38] [[File:Foo.jpg]] has a default link to File:Foo.jpg. [18:24:57] cscott: I don't know. Inez thought that way back in like September or whatever and it clearly works better than the alternative [18:25:02] I realize that's not a good justification :) [18:25:17] I can't manage to spot the bug that was reported, though [18:25:38] cscott: If you have a better suggestion for that we should put there, we'd be happy to hear it :) [18:26:19] cscott: Also, it turns out you were the one that filed the bug for the workaround to be undone :) https://bugzilla.wikimedia.org/show_bug.cgi?id=61560 [18:26:44] the fundamental question is: is there some case where [[File:Foo.jpg]] has a default link that's not equivalent to [[File:Foo.jpg|link=File:Foo.jpg]]? [18:27:09] i don't think so, so i think that setting link = this.title by default is the Right Thing. [18:27:26] Right [18:27:33] At first glance that seems reasonable [18:27:34] hello [18:27:40] For whatever reason it didn't work in practice [18:27:42] But I don't know why [18:29:52] Hey InezK. [18:29:58] Also, hey kflorence. :-) [18:29:59] well, parsoid's image handler has been very broken at times. but i think the correct-by-the-spec think is for a[href] to equal img[resource] by default. if it is different, we will emit a link option in the wikitext. [18:30:11] that matches what the code is doing now, so i think the related bugs can be closed. [18:35:16] https://www.mediawiki.org/w/index.php?title=Parsoid%2FMediaWiki_DOM_spec&diff=931265&oldid=931084 <- clarified the spec [18:40:38] https://gerrit.wikimedia.org/r/119087 <- add comment in VE source to clarify [18:47:44] hi [18:48:46] Hi [18:49:47] how we are doing? [18:50:08] cscott: That doesn't clarify, that confuses. Linking to bare URLs without explanation for code that's fine is just confusing. [18:50:20] cscott: Unfortunately RoanKattouw just merged it. *sighs* [18:50:24] James_F: feel free to improve the patch! [18:50:44] cscott: I did, in https://gerrit.wikimedia.org/r/#/c/119088/ :-) [18:50:53] I'm just suggesting that the old commented-out code should be removed, since there's no way it could be correct. [18:51:17] (It turns out that not having grrrit-wm bot is really unhelpful.) [18:51:25] judging from the gerrit numbers, i clearly won that race. ;) [18:51:33] :-) [18:53:02] anyway, i'll let you guys figure out how to resolve the conflict, and close 61560 when you're done. [18:53:09] * James_F is doing so. [18:53:11] i'm going to go back to making 'upright' work in parsoid for mooeypoo [18:54:05] Awesome. :-) [18:54:12] wooohoo [18:55:03] I cant launch VE on en [18:56:36] Juandev: Works fine for me. What browser? [18:58:07] FF [18:58:12] nor GoogleChrome [18:59:21] could it be caused by personal js? [19:01:42] its not blocked by any Gadget [19:02:10] Juandev: Does https://en.wikipedia.org/wiki/User:Jdforrester_(WMF)/Sandbox?veaction=edit work in a Chrome incognito window? [19:02:48] ah, maybe I should try FF safe mode [19:03:40] Can you expand on 'cant launch'? Are you getting an error (as an alert or in the JS console)? Does it start loading and then revert back to viewing mode? [19:04:09] James_F: yes [19:04:43] Krenair: in Chrome it doesnt work at all, in FF it is launching [19:04:49] Juandev: If it works logged out but not logged in, it's a bug in a gadget or a personal script, probably. [19:04:56] Okay. Do you know how to view the JS console? [19:05:10] seemingly it doesnt work, when I log in. I can edit when I am logged off [19:05:31] so its account related not browser related [19:05:41] (I have to go AFK for dinner now, sorry) [19:06:01] We're heading out for lunch in a bit [19:06:06] Krenair: I have a webdeveloper plugin in FF it doesnt show any errors [19:06:37] Krenair: it starts loading and its still loading in FF [19:08:24] well not a gadget, so it should be PS [19:10:41] no! [19:11:12] is there a way to analyse whats going on when launching the session? [19:12:55] could someone to whom it works, compare user preferences? [19:16:22] umm it works under my previous account [19:19:54] since when a random VEdit can get rid of useless ^{tags (previously added by VE itself?)
[19:24:24] Elitre: Last week, maybe? But it shouldn't be removing them unless you change the text…
[19:29:14] so I havent found a problem
[19:29:32] is there any option to block a user from editing via VE?
[19:30:08] James_F: it removes them on unrelated edit, it seems: https://fr.wikipedia.org/w/index.php?title=Utilisateur%3AElitre_%28WMF%29%2FProve2&diff=102142609&oldid=102142596 I wanted to show appreciation :)
[19:33:09] Juandev, not without fully blocking them from editing
[19:33:57] Krenair: so maybe it is related to any other user right?
[19:34:28] Juandev, what?
[19:35:37] well, I have tried that under previous account and it works, whyle with the actuall account it doesnt work. so I wonder it might be related to a permission: https://www.mediawiki.org/wiki/Manual:User_rights_management#List_of_permissions
[19:38:52] Juandev: No, it means that you've got a script, gadget or preference that breaks VisualEditor for you.
[19:39:03] Juandev: There are no userrights related to VisualEditor.
[19:39:19] James_F: but I have tried all of that twice
[19:39:34] I removed gadgets and deleted userscripts
[19:40:04] those userscripts in my ns
[19:40:25] could be there other script related influencing my account?
[19:40:48] Juandev: Yes, potentially. Which page?
[19:41:42] well sometimes on en, when you want to use a feature, you have to register somewhere and they add you in
[19:42:09] This is not the case for VisualEditor, however. :-)
[19:43:48] so I am broken than
[19:43:53] I tried to switch of my preferences, removed content from js files and it didnt work
[19:44:12] :-(
[19:44:18] than I compare settings with my previous account which works and it didnt work
[19:44:30] so maybe personal CSS?
[19:45:28] I have just monobook.css, while using vector right now, that is highly unlikely a problem
[19:56:41] so no Juan with VE on en.wp
[19:57:57] Juandev: Does it work in Vector/
[19:57:58] well, more heads more ideas=village pump
[19:58:07] no it doesnt work in vector
[19:58:16] Hmm. :-(
[20:01:12] oh man, I found it
[20:01:17] I had common.js
[20:01:40] https://en.wikipedia.org/w/index.php?title=User:Juandev/common.js&diff=600056718&oldid=516703367
[20:02:05] Reedy or Wikitrust caused it
[20:03:05] James_F: so you were right
[20:05:04] so it was caused by this script: https://toolserver.org/~netaction/wikitrust.js
[20:13:57] btw, why cs doesnt have VE creation?
[20:22:20] cool you load template parameters on cs with a description
[20:22:28] you have a beer guys
[20:22:33] what about at en?
[20:23:19] /back
[20:23:31] Juandev: If there's TemplateData defined for the template, we load it
[20:23:47] So it depends on whether the enwiki community wrote documentation for that template
[20:23:47] what is template data?
[20:23:55] ah doc
[20:23:56] good
[20:23:56] It's structured documentation for a template
[20:24:16] Like /doc but in a more structured format so our software can understand it and use it to populate stuff in VE
[20:24:23] how you chose which documentation to load?
[20:24:55] we have on cs short and long versions and in this one case I have just opened it looks you are loading short version:-)
[20:26:37] Juandev: Can you link to an example template? Then I can show you
[20:30:24] James_F: ahoy
[20:30:26] yep
[20:30:40] James_F: you can't get rid of me that easy ;)
[20:31:24] RoanKattouw: https://cs.wikipedia.org/wiki/%C5%A0ablona:Citace_webu
[20:33:12] kflorence: Good. :-)
[20:33:14] RoanKattouw: on the other side its English verion has also to dogs, but VE loads only 2 lines: https://en.wikipedia.org/wiki/Template:Cite_web
[20:33:36] URL and Source title
[20:33:41] Juandev: https://cs.wikipedia.org/w/index.php?title=%C5%A0ablona:Citace_elektronick%C3%A9_monografie/doc&action=edit§ion=T-14 is where the TemplateData lives
[20:34:09] anyway, nice expression "where the TD lives"
[20:34:25] https://en.wikipedia.org/wiki/Template:Cite_web#Template_data must be different from https://cs.wikipedia.org/wiki/%C5%A0ablona:Citace_elektronick%C3%A9_monografie/doc#Data_.C5.A1ablony somehow
[20:34:55] RoanKattouw: good to know, could reccomend it to the local community to use it more
[20:35:15] The two lines you see on English are because there are two params marked as required
[20:35:21] So it loads those two
[20:35:32] But the other params do have docs, the docs look pretty complete actually
[20:35:48] The cswiki version doesn't define any params as required
[20:36:36] And so it initially loads as empty and you have to add all params manually
[20:36:39] James_F: so you speak Czech?
[20:36:48] While on enwiki the two required params show up right away
[20:36:52] Juandev: No, sorry.
[20:37:03] Juandev: No one on our team speaks Czech AFAIK
[20:37:23] nor kflorence?
[20:38:29] RoanKattouw: so VE reads from where starts?
[20:38:37] Juandev: Yes.
[20:38:56] Juandev: Actually, TemplateData does, and VE just asks TemplateData for the details. But yes.
[20:39:27] Juandev: I don't speak Czech, but I drink it :)
[20:39:34] so if "required" is true, that those data should go for sure
[20:39:52] kflorence: yep, thats what we understand
[20:40:02] "required" means "if you're not using this parameter, you're probably doing something wrong"
[20:40:14] We don't actually make it hard required, i.e. VE won't fail or yell at you if you don't use it
[20:40:24] Currently.
[20:40:25] It'll just strongly suggest that you use it by putting it right in your face
[20:40:27] We might change that.
[20:40:28] Currently, yes
[20:40:36] and...
[20:42:39] RoanKattouw: so what "tells" VE to read the short version in cs? I dont see any special options in templatedata
[20:42:52] Short version of what?
[20:43:06] less parameters
[20:43:44] it use those parameters on the right: https://cs.wikipedia.org/wiki/%C5%A0ablona:Citace_elektronick%C3%A9_monografie/doc
[20:43:58] Hi! I've got some questions about Template Data too, i guess ;) I see there's already a discussion going on. May I enter it, too?
[20:44:13] That's weird because they're definitely all documented
[20:44:22] Juandev: What /exactly/ do you do to reproduce this bug?
[20:44:24] Fannon: Feel free
[20:44:53] sorry, taking back
[20:45:06] Right now I've understood Template Data as some first step into having a form-builder, right?
[20:45:10] its loading all params in TD
[20:45:35] Will it be possible to have different Kinds of Form Inputs and Validation?
[20:46:14] Fannon: Yes. Which kinds were you thinking?
[20:46:20] James_F, fiddled around with the edit notice box for huge notices again, don't have many ideas beyond giving it a set height and a scrollbar: https://dl.dropboxusercontent.com/u/10971457/Wikimedia/VisualEditor/Blocked%20text%20edit%20notice%20scrolling%20WIP.png
[20:46:41] (tested using a simple copy of enwiki's MediaWiki:Autoblockedtext without templates etc.)
[20:46:47] Right now i'm thinking about the Drupal Form Builder.. you know it?
[20:46:51] Krenair: Eww. Is that 40em rather than 20em or whatever?
[20:46:56] Fannon: I don't, know.
[20:47:01] Err.
[20:47:05] Fannon: I don't know it, no.
[20:47:35] Ok, wait - i'll send you a screenshot
[20:47:45] James_F, I doubled the width, yeah. Otherwise it looks even more ridiculous
[20:48:03] Krenair: To an extent those are issues for individual wikis' communities to fix. :-)
[20:48:25] James_F: https://www.dropbox.com/s/ddlkg1qgsflz2n3/2014-03-17_-_21-47-42.png
[20:49:53] sorry, it's german. But the Idea is that you can declare a datatype / range / class for the value of the field
[20:49:57] Fannon: Ah, so it's like https://www.dropbox.com/s/4ayagumgsg8lb66/Screen%20Shot%202014-03-17%20at%2013.49.13.png
[20:50:01] and then select how its displayed
[20:50:05] in the form
[20:50:24] so if you want a dropdown menu, multiple choice widget, autocomplete, etc
[20:50:25] Fannon: That code is in testing and not released to wikis yet, but allows for easy editing of the data.
[20:50:41] Fannon: We haven't done a nice typing system in that yet, but that's how you would do it.
[20:50:51] Fannon: Does that look reasonable?
[20:50:55] ah, that looks very similar
[20:50:56] yes
[20:51:13] Cool. We should make sure it's ready to go and release it, then. :-)
[20:51:30] ok, thanks :) Great work on the Visual Editor btw.!
[20:51:38] Thank you. :-)
[20:51:49] I've got one more general question
[20:51:52] Sure.
[20:52:09] currently im studing / working in research
[20:52:17] OK.
[20:52:32] and one project is about getting forms and workflows into mediawiki
[20:52:41] in combination with Semantic MediaWiki
[20:53:00] I would have some time for developing and contributing to open source projects
[20:53:12] right now I'm thinking about using the VisualEditor as my start point
[20:53:13] since I
[20:53:31] * James_F nods.
[20:53:37] since i'm not very happy about some aspects of the semantic forms component
[20:53:49] James_F, okay, I got rid of the width change. I kind of feel that the height restriction and scrollbar is necessary because on short articles part of the edit notices could become inaccessible otherwise,
[20:54:03] I'm not sure if this is realistic. Visual Editor is a big project
[20:54:38] thats boring to add parameters on every single wikipedia, I had to go to code and done it in the code
[20:54:39] But ideally i would like to replace the semantic form component with VisualEditor. Put the Form Logic where it belongs (into the template)
[20:56:08] So if this is reasonable I could experiment with that and contribute my ideas if your team / project likes that
[20:56:41] Krenair: Yeah, we could keep the width change, I'm just concerned that we shouldn't develop VE just around the needs of one badly-thought-through template on one wiki.
[20:57:07] Fannon: Yeah, that could work.
[20:57:57] Krenair: Did you do anything special to make edit notices scrollable? I seem to recall there's a bug about that being broken
[20:58:25] yeah, added overflow-y: scroll; to the CSS, heh.
[20:58:49] hah
[20:58:56] Krenair: I think there's some magic mixin of TrevorP|Away's that does it nicely, but that works. ;-)
[20:59:12] ClippableElement
[20:59:17] Yeah.
[20:59:18] Not sure if that would work in this context
[20:59:24] But you could ask TrevorP|Away
[20:59:29] Definitely, it won't work in Monobook. :-)
[20:59:32] Who needs to not be /away because he's at his desk
[21:00:20] James_F: Great! Well, I've still got to evaluate this option. But if this works, could I talk to somebody from your team about this more in depth?
[21:00:22] ClippableElement is broken in monobook, yeah - I've heard this before...
[21:01:12] RoanKattouw, Oh and I had to set the height otherwise it would just flow off the screen and not use the scroll bar
[21:01:17] Yeah
[21:01:25] So that's what ClippableElement can solve for you
[21:01:37] Fannon: Yes, completely. Krinkle|detached was the main person behind TD itself, mooey was the one on the form editor, and we all care about it, so… :-)
[21:01:39] It constrains the height to the available height on the screen or in the container
[21:01:54] Which is why it breaks in Monobook, because Monobook is Broken By Design™.
[21:02:30] How about we add body { height: 100% } to skins/common.css or whatever?
[21:04:16] James_F: Ok! Then I'll make a concept of how I'd like to extend VE / TD and we could discuss about it. This could take a few days / weeks since I have to consider some options and maybe have some more students working on this, too
[21:04:56] Fannon: Of course. :-)
[21:05:06] James_F, didn't I propose that before?
[21:05:54] Oh yeah: https://gerrit.wikimedia.org/r/#/c/117241/
[21:05:59] Krenair: Yes, and I said it sounded good, but then you tried to fix Monobook and MatmaRex said he preferred not having to fix individual skins.
[21:06:37] in fact i preferred to fix OOjs instead :P
[21:07:01] MatmaRex: OOjs isn't broken, though.
[21:07:05] i provided two possible OOjs solutions on the bug, but someone who knows what they're doing should look at them
[21:07:15] James_F: well, depends on how you look at it
[21:07:17] MatmaRex: Making things in sub-elements sized to the sub-element is totally reasonable behaviour.
[21:07:29] in CSS, it's perfectly reasonable for body ot have a height on 0 :P
[21:07:34] MatmaRex: If MW is so amazingly broken that it's going to choke on that requirement, we need to fix MW.
[21:07:49] well, have a peaceful time
[21:07:49] MatmaRex: Your meaning of "perfectly reasonable" differs from mine.
[21:07:54] going to sleep
[21:07:59] James_F: as i said, "in CSS"
[21:08:18] MatmaRex: Your understanding of what CSS thinks is "perfectly reasonable" differs from mine.
[21:08:24] James_F: if you don't set body's height to anything, you should expect the default value to be there, which might be 0 in some cases
[21:08:30] i mean
[21:08:33] MatmaRex: I'm aware.
[21:08:34] this has nothing to do with MW's skins
[21:08:47] OOjs will fail on any site that doesn't set body{height:100%}
[21:08:55] Not true.
[21:09:02] vector happens to set that, don't ask me why
[21:09:08] i am pretty sure that is, in fact, true.
[21:09:10] OOjs will fail inside something that doesn't have a height.
[21:09:21] Absolutely positioning the entire skin is ludicrous.
[21:09:31] James_F: no! that's not the issue
[21:09:43] James_F: it's OOjs that does absolute positioning of all of the elements on one of its dialogs
[21:09:52] or OOjs UI i guess, whatever
[21:10:04] then that dialog's body's height is 0
[21:10:34] it isn't on Vector, because Vector does body{height:100%}, and OOjs copies that to the dialog's iframe
[21:10:46] this has only ever worked by pure chance
[21:10:56] i am absolutely positive about that
[21:11:01] Well, yes, iframes should inherit the CSS of their parent document unless you have a good reason not to do so.
[21:11:07] no, they shouldn't
[21:11:10] they don't in HTML
[21:11:17] Oy.
[21:11:17] you guys hacked that in :D
[21:11:35] "Well, yes, iframe sub-documents of a document should always be set to inherit the CSS of their parent document."
[21:11:42] iframes are entirely separate documents, allowing sites to "inject" CSS into them is basically a security issue
[21:11:46] No, it's not a hack, it's a design decision.
[21:12:19] (unless you create the iframe and its document yourself in JS, but the browser doesn't know that in general)
[21:12:41] anyway
[21:13:06] as i said, that issue will happen on every site that doesn't set body{height:100%}
[21:13:28] if you expect sites using OOjs to do that, document it (but it sounds like a very silly expectation to me)
[21:16:48] someone should fix the bug in OOJS-UI's ClippableElement so that it doesn't assume the body height is 100%
[21:17:14] (i'm pretty sure i said that on the bug :P)
[21:17:28] sweet, we agree
[21:44:17] James_F: The Screenshot you showed me a while ago about the VE Forms.. is this feature in the master branch available? How do I find it?
[21:46:49] Fannon: which screenshot?
[21:47:02] https://www.dropbox.com/s/4ayagumgsg8lb66/Screen%20Shot%202014-03-17%20at%2013.49.13.png
[21:48:16] we plan to deploy that, it's part of the TemplateData extension and it can be enabled using a global variable
[21:48:28] but we might convert it to use OOUI-JS before we deploy it
[21:48:45] *OOJS-UI...
[21:48:46] TrevorParscal
[21:48:57] ok!
[21:49:22] If i want to play / contribute around with that, anything to mind?
[21:49:43] mooey: ??
[21:50:08] Fannon, feel free. If you have any questions I'd be happy to help
[21:50:44] mooey: thanks! youre developing this feature right now?
[21:51:07] I worked on that, yeah. It's deployed in the TemplateData extension, but you need to enable it with the flag in local settings
[21:53:23] mooey: where do I find the TemplateData Extension?
[21:54:25] git clone ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/TemplateData.git
[21:54:26] Fannon: https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FTemplateData.git
[21:55:09] thanks!
[21:57:58] mooey: I've already talked with James_F a bit. Maybe I can work / contribute on this for a while. But right now i'm still evaluating some options}