[01:22:33] Eloquence: Hey, is there someone in specific who already has a labs project for phabricator? Reedy said johnduhart was the person to ask. [01:22:47] s/in specific/in particular/ [01:23:44] I can't remember what it was named [01:23:55] https://labsconsole.wikimedia.org/wiki/Nova_Resource:Phabricator [01:24:07] Hosts look to have been removed.. [02:30:58] marktraceur, yeah johnduhart had it set up for testing a few months ago, but it may be easier to set it up from scratch at this point [02:34:53] Eloquence: Hrm, I wonder if it's likely that I can get ownership of a labs project now.... [02:35:21] * marktraceur may as well set up Phabricator on another computer first [03:49:38] marktraceur: i'm going to try setting it up on labs now, wanna help? [03:51:02] ori-l: If you need anything from me, I'd be happy to--I'm busy trying to set up review.marktraceur.info, but I'm willing to process in parallel [03:51:16] (and I'm waiting for DNS changes now anyway) [04:02:30] Wow, that went better than expected so far....DNS records being slow, but otherwise good [04:03:14] marktraceur: there's no one around to add us to the labs projects, but if you want we could try our hand at a puppet config [04:05:30] ori-l: Sounds fun! Do you know where the docs are for that? I've never done it before. [04:06:03] i'm the worst person in the world when it comes to knowing where things are [04:06:50] but you can start by doing a git clone of ssh://your_user_name@gerrit.wikimedia.org:29418/operations/puppet.git [04:08:21] i don't absorb information amazingly well unless i'm actively trying to do something with it, so i was going to pick the puppet manifest of something that seems closeish to phabricator (maybe mediawiki, because it too runs on php and a web server) and see how far i get by tweaking it [04:09:14] if you want to work on it with me join #phab [16:33:18] will parsoid become the parser for all pages one day? [16:43:52] liangent, that is the goal, yes. /cc gwicke [16:45:59] liangent: not likely to happen this year though ;) [17:13:57] so it will cover every nasty edge cases? [17:15:49] or declare them as invalid wikitext? [17:16:44] gwicke: ^ [17:17:26] AaronSchulz: can you tell me anything about the state of image handling on test2, e.g this recent file doesn't look healthy http://test2.wikipedia.org/wiki/File:Just_another_test_upload_05.jpg [17:17:53] AaronSchulz: I spoke too soon, it looks healthy now, it didn't a few minutes ago. [17:51:52] liangent: sorry, was afk [17:53:08] liangent: we are trying hard to cover all important edge cases, and to identify those we cannot handle so that they can be handled by preprocessing the wikitext or manually fixing templates [17:53:53] liangent: some issues are listed in http://www.mediawiki.org/wiki/Parsoid/Todo#Limitations [17:56:04] gwicke: seems #1 and #3 are used around wikis [17:57:40] liangent: yeah, fortunately those are easy to fix up without loss of functionality [17:58:12] we *might* also be able to write a tool for those fixups, but that is less certain [17:58:21] gwicke: but there'll be too many places to fix [17:58:45] liangent: so far the issues only concern a handful of templates [18:01:25] liangent: there are likely some more, but I'm still optimistic that we'll be able to handle those, especially if the really complex stuff is ported to Lua anyway [18:01:41] gwicke: I have this template http://zh.wikipedia.org/w/index.php?title=Template:Wraptext&action=edit [18:02:20] and I'm using it in infoboxes in this way: {{wraptext|{{!((}}|{{{my_infobox_field_data|}}}|{{))!}}}} [18:02:26] will this be affected [18:03:06] liangent: if you have a sample page that includes that template, then you can try it at http://parsoid.wmflabs.org/zh: [18:05:15] gwicke: nice, it's broken: http://parsoid.wmflabs.org/zh:User:Liangent/test and http://zh.wikipedia.org/wiki/User:Liangent/test [18:05:20] so how should I fix it? [18:06:54] liangent: the basic principle is to include the full link in the template, rather than just the start/end chars [18:07:45] liangent: in your case that would yield a less general template, say linktext [18:09:27] hmm I'm using it for files too, like {{wraptext|{{!((}}File:|{{{infobox_data|}}}|{{!}}250px{{))!}}}} [18:09:42] gwicke: so it would lead to some more templates [18:10:51] liangent: on the English Wikipedia, [[Template:!((]] does not seem to be that popular though [18:11:24] more popular on zh though [18:12:15] 587 transclusions apparently [18:12:47] we can always add hacks for specific templates to lessen the burden of manual conversions [18:13:22] fortunately most of the difficult things are only accessed indirectly through other templates [18:13:41] gwicke: I guess some (or most) of them are used by me in infoboxes [18:14:09] I'm converting old hiddenStructure infoboxes in this way [18:14:58] how many of those infoboxes are there in your estimation? [18:15:49] replacing one template call with another is something that should be relatively easy to automate, even using simple regexps [18:15:56] or a bot [18:16:22] gwicke: not so many. I bet most of them were introduced in my conversion [18:16:59] ok, that sounds not too bad then [18:18:42] liangent: I linked the Wraptext template from the limitations section so we remember to deal with it [18:19:21] so I should stop using it? I'm using it to simplify my conversion work. in this way I can simply convert [18:19:21] |- class{{{data|}}}="hiddenStructure" [18:19:22] | labeltext || some mixed string of {{{data}}} and others [18:19:22] to [18:19:22] |labelN=labeltext [18:19:22] |dataN={{wraptext|some mixed string of |{{{data|}}}| and others}} [18:20:12] so if "others" contain wikimarkups I'll use {{!((}} etc [18:21:30] liangent: this kind of template will always be hard to support in a single-pass tokenizer, which we kind of need if we want to preserve provenance info for round-tripping [18:22:18] are you already analyzing others for wikitext so that you can replace it with {{!))}}? [18:22:54] if so, then maybe wrapping a Linktext template around {{{data}}} might be an alternative [18:23:29] I would not be surprised if there was already such a template [18:26:59] gwicke: in my conversion, {{wraptext|{{!((}}|{{{my_infobox_field_data|}}}|{{))!}}}} is not the most popular one [18:27:11] the most popular is {{wraptext|{{!((}}File:|{{{infobox_data|}}}|{{!}}250px{{))!}}}} [18:28:39] that sounds doable too with some conditionals to handle the namespace and extra parameters [18:29:00] but would admittedly place a higher burden on your conversion [18:35:12] ugh, so many substitution templates - so big hell for parser [18:36:25] gwicke: actually I can use {{#if:{{{infobox_data|}}}|[[File:{{{infobox_data|}}}|250px]]}} but {{{infobox_data|}}} is repeated now [18:36:46] liangent: beside |- class{{{data|}}}="hiddenStructure" is ugly hack, it won't work properly if somebody will call {{template|data=}} [18:36:53] so if {{{infobox_data|}}} is some template call it can be more expensive [18:37:34] Danny_B|backup: it's usually expected to hide the row with |data=}} [18:37:49] it's unwanted to show a infobox field with no data [18:37:51] liangent: the results of template calls are normally cached / shared, so the overhead of calling the same template twice with the same parameters is quite small [18:37:51] but it won't [18:39:02] gwicke: eh? I remember it's mentioned somewhere that call to the same template with some arguments are not shared even if the arguments are the same? [18:39:14] oh wait, you have pipe there, sorry, i missed it [18:39:29] nvm, it's still ugly hack though... [18:39:46] liangent: templates are expected to be side-effect free, so sharing expansions is legal [18:39:56] within a single request [18:40:05] it's it shared currently..? [18:40:22] liangent: afaik yes [18:40:54] we share it without ill effects in Parsoid too [18:41:23] gwicke: but http://en.wikipedia.org/wiki/Wikipedia:Template_limits#Post-expand_include_size says [18:41:32] in the future these template expansions can mostly be optimized away anyway, unless the template changes or the output depends on something like the time [18:42:18] Template invocations with no arguments have an expanded text cache. ... But if you included the same template multiple times with {{foo|arg}}, then the secondary templates are counted each time, even if the argument is the same. [18:42:59] liangent: that might be a limitation of the current PHP implementation [18:43:26] we hash the template name and parameters and use that as the cache key [18:44:25] also, the statement about the PHP implementation is more concerned about the include size counter [18:44:30] gwicke: the same for parserfunctions? [18:44:54] it doesn't say very much about the actual execution overhead [18:45:10] liangent: yes [18:45:47] liangent: the timestamp for example will be the same anywhere in the page [18:46:00] even on pages that take several seconds to render [18:46:39] gwicke: so these extensions will fail?: http://www.mediawiki.org/wiki/Extension:Counter [18:47:41] liangent: yes, unless we add a way to register side-effectful parser functions [18:48:06] that would then disable caching for any content affected by them [18:48:48] sounds not so good I guess [18:51:05] more precise dependency tracking lets us render pages faster [18:57:01] gwicke: will you touch the language converter then? [18:57:30] liangent: we did not work on that yet, but will have to eventually [18:59:23] liangent: we can always adjust parserfunctions that are in our repos to more precisely describe their cache / sharing ability [19:00:12] yeah and that's an advantage of putting code here [19:01:09] could also make the default configurable, so that you can keep things working (but slower) for other parser functions [19:01:33] afk for a moment, lunch.. [20:25:31] gwicke: how do you consider {{!}} then? [20:25:49] I believe it's widely used across wikis to generate table syntax [20:27:27] indeed [20:36:57] liangent: we added a special-case production to the tokenizer that just defines this as an alternative syntax for tables ;) [20:37:57] that seems to cover practically all use cases we have encountered so far [20:38:42] so I can't use [[Template:!]] for others? [20:39:03] then it's creating nasty things in the new parser [20:40:31] gwicke: for example: in template we have: [[{{{name}}}]], in page I use {{template|name=real{{!}}display}} [20:41:02] and it's used in real world [20:41:39] liangent: that would just result in a plain pipe char [20:42:14] still bad then... [20:42:59] gwicke: and [[ ]] gets to plain brackets as the content has invalid title characters? [20:43:17] we are not very picky about title chars at the tokenizer level [20:43:29] this is a good learning experience for me understanding templates and the varied uses they are put to ... [20:44:19] it would in any case be recognized as a wiki link in the tokenizer [20:44:28] later stages might flag it as invalid if we added that [20:45:16] I didn't understand the [[Template:!]] discusssion. can i ask a question? [20:45:51] so, what is the problem with the {{!}} parser rule handling the scenario that liangent pasted above? [20:45:52] liangent: there are other ways to get a similar effect without relying on multi-pass parsing [20:46:20] subbu: that template is often use to escape pipe characters in template parameters [20:46:53] right. so, why is liangent saying it is bad to display a plain pipe char [20:47:05] those are often part of table syntax, so I added productions that recognize table tokens marked up that way in the tokenizer [20:47:30] the PHP preprocessor produces different wikitext as its output [20:48:05] so [[{{{name}}}]] expands to [[real|display]] [20:48:06] aha .. i think i understand now ... so, {{template|name=real{{!}}display}} ==> {{template|name=real|display}} so, the pipe is not plain text but a syntactic element? [20:48:20] which is then recognized as a link in the later parser pass [20:49:22] similar for tables, but we work around that by directly recognizing that pattern in the tokenizer [20:49:33] got it .. hmm ... so, the semantics are: whatever the php preprocessor expands in the first pass becomes syntactic elements rather than plain text as in a 1-pass .. [20:49:46] ok. [20:51:21] i should read the scrollback ... looks like there is other discussion there. [20:52:50] subbu: around the first point of http://www.mediawiki.org/wiki/Parsoid/Todo#Limitations [20:53:50] ok, thanks. [20:55:13] gwicke: when is / processed? [20:55:39] liangent: in token stream transforms [20:56:03] the tokenizer just produces a token with that info [20:56:23] I don't really understand.. let me create some test cases [20:56:49] liangent: we tokenize everything in a single pass [20:56:56] then transform the token stream [20:57:15] (that includes template expansion etc) [20:57:26] and finally build a DOM from the resulting tokens [20:58:15] there is a fancy ASCII illustration at http://www.mediawiki.org/wiki/Parsoid/Token_stream_transformations#Template_expansion ;) [20:59:52] http://zh.wikipedia.org/w/index.php?title=User:Liangent/test&action=edit [20:59:54] fails [21:00:08] diff from phpparser and parsoid [21:01:08] http://zh.wikipedia.org/wiki/User:Liangent/testb fails again AND we really have people like to write this [21:01:23] to display the position of an argument on template page [21:01:47] gwicke: ^ [21:02:15] hmm- that is tricky [21:03:04] we have mostly stopped to work on edge cases since June and instead focused on round-tripping and serialization [21:03:22] but we'll get back into that eventually [21:04:47] added this to http://www.mediawiki.org/wiki/Parsoid/Bug_test_cases so we remember to look into it [21:06:01] the work-around would be something like {{{arg|}}}{{{arg}}} [21:08:41] gwicke: {{echo|abcdef}} how can this fail too? [21:08:50] I think this is a very normal use case [21:09:02] that should work [21:09:14] http://parsoid.wmflabs.org/zh:User:Liangent/test but doesn't work [21:09:16] since it does not change the syntax really [21:09:21] then it is a plain bug.. [21:10:15] so? [21:11:10] liangent: I think we are currently transcluding all pages to simplify our web API code [21:12:37] hmm [21:12:43] I'm adding one: http://www.mediawiki.org/w/index.php?title=Parsoid/Bug_test_cases&diff=569900&oldid=569899 [21:12:48] http://parsoid.wmflabs.org/mw:Parsoid/Bug_test_cases [21:15:14] yeah, noinclude sections are removed and includeonly sections are rendered since we are transcluding the page [21:15:51] gwicke: nope, parsoid does correctly for line 2 on http://parsoid.wmflabs.org/zh:User:Liangent/test [21:19:57] in http://parsoid.wmflabs.org/mw:Parsoid/Bug_test_cases it renders the includeonly section, but removes the noinclude one [21:21:32] the difference is that one is directly in the top-level context, while the other is in a template parameter [21:22:07] gwicke: well in either case (transcluded or directly viewed) they should be the same http://www.mediawiki.org/w/index.php?title=Parsoid%2FBug_test_cases&diff=569905&oldid=569903 [21:22:12] but in parsoid they're not [21:22:17] so our bug is that we mistakenly use include context for the expansion of noinclude etc in template parameters [21:22:34] even if the parameter originated in the top-level page [21:23:02] good catch ;) [21:29:00] gwicke: what's the relationship between http://www.mediawiki.org/wiki/Parsoid/Bug_test_cases and bugzilla? [21:29:28] kaldari: Hey I'm about to deploy the fix for bug 37331 . Do you have PageTriage running on testwiki or mw.org by any chance? [21:29:30] we often use bug test cases for convenience, but bugzilla is really the better place for discussion etc [21:29:52] (Cause the fix is in 1.20wmf9 already and that's running on those two wikis, I'm just backporting it to wmf8 so you'll have it sitewide) [21:29:57] RoanKattouw: yes, it's running on test [21:30:08] OK [21:30:15] You should be able to turn on the curation toolbar there already [21:30:19] liangent: https://bugzilla.wikimedia.org/enter_bug.cgi?product=Parsoid [21:30:22] Because test should already have the RL bug fix as of esterday [21:30:25] *yesterday [21:30:45] OK, I'll turn it on there. Gimme about 20 minutes. [21:30:54] I've also got a backport to wmf8 lined up that I'm about to deploy to all wikis if you're around to test it for me [21:31:06] gwicke: I knew it because someone massmoved some bugs reported by me to that product [21:33:31] gwicke: http://www.mediawiki.org/w/index.php?title=Parsoid/Bug_test_cases&diff=569914&oldid=569912 "slash tricks" not supported yet? [21:34:01] I have a git predicament here if someone has a sec. I'm trying to rebase a change I made. I downloaded my change from gerrit, made my changes, commited, and rebased. After my rebase, git status says "nothing to commit (working directory clean)" [21:34:15] liangent: no, full link target resolution is not implemented yet [21:34:28] that is just porting though, nothing hard [21:34:58] ok and [[San Francisco, California|]] is not supported in php parser [21:35:11] nullspoon: What's the problem? [21:35:33] liangent: mark implemented that yesterday, let me update the code on parsoid.wmflabs.org.. [21:35:45] there are more test modes listed at http://parsoid.wmflabs.org/ [21:36:29] gwicke: I mean [[San Francisco, California|]] is rendered plain in php parser except for PST. do you want to render it as a link in parsoid? [21:36:31] marktraceur: I'm not sure exactly. My commit log is now empty and git shows there are no changes. [21:36:58] and by commit log I mean .git/COMMIT_EDITMSG [21:37:09] not git log [21:37:41] liangent: we support that on the way out since we don't implement any PST right now [21:38:17] nullspoon: You know you don't need to commit to finish a rebase [21:38:18] so what about {{subst: [21:38:43] nullspoon: That's largely the point, it's not a merge :) [21:38:45] some or lots of templates are depending on the difference between PST and normal parsing [21:38:50] gwicke: ^ [21:40:15] spotty office internet.. [21:40:23] marktraceur: During my rebase I had some conflicts with RELEASE and CREDITS. I merged the changes and did git add for both files and then git rebase --continue [21:40:54] marktraceur: somewhere in there my commit log was wiped [21:41:04] I should research more before I ask a question I suppose. [21:41:14] liangent: we don't support subst yet, but know that we'll eventually have to support at least some of it [21:41:45] some of the PST functionality can also be moved to the VE [21:41:55] signatures, timestamps and the like [21:48:08] liangent: https://bugzilla.wikimedia.org/post_bug.cgi [21:48:10] sorry.. [21:48:19] https://bugzilla.wikimedia.org/show_bug.cgi?id=39113 [21:48:52] gwicke: I saw it in #mediawiki [21:49:13] liangent: ok, thanks for your report! [21:49:31] so is it not so easy to fix? [21:49:37] like an one-line change? [21:49:57] it's just like flipping something around [21:50:27] kaldari: I gotta do an interview 3pm-4pm but after that I'll deploy the backport to wmf8, will you be around at say 4:15pm to help me test it? [21:50:39] sure [21:50:39] liangent: it should be quite easy to fix, but perhaps more like 3-4 lines [21:51:22] am working on template encapsulation right now [21:51:37] so that will have to wait for now [21:52:08] how does template editing look like in VE? [21:52:24] liangent: there is none so far, and it won't be visual in any case [21:52:49] I'm working on establishing the DOM trees at least partially generated from template output [21:52:57] so that the VE can protect that content [21:53:10] so it's uneditable in VE [21:53:13] in the longer term we might offer inline template parameter editing [21:53:43] so you could change the population of some city by clicking into the rendered infobox [21:54:02] we have some (even quite widely used) inline templates and this may trouble VE users [21:54:41] liangent: what do you mean with 'inline'? [21:54:57] table start / row / end templates? [21:55:18] for example, we write: '''Jimmy Wales''', {{born and death date|August 7|1966|||}}, ... [21:55:50] ah, you mean templates producing just text? [21:55:51] and the template displays (born August 7, 1996) and put the article into 1966 births and living people [21:55:57] Or "San Jose is {{convert|70|mi}} south of San Francisco" [21:56:06] yeah [21:56:11] we are encapsulating plain text into spans [21:56:11] Which renders as "San Jose is 70 mi (112 km) south of San Francisco" [21:56:33] (plain text produced by templates) [21:57:04] actually we don't do that yet, but I hope we'll do so tonight ;) [21:58:30] gwicke: what about template pairs where one generates

and another does

[21:59:12] liangent: the produced DOM subtree will have attributes set on its root [21:59:39] so..? I don't understand [21:59:41] on each root, if it produces several sibling nodes [21:59:59] nullspoon: Yeah, you should never add a commit during a rebase [22:00:04] That's the whole point of rebases [22:00:20] (also, lol @ the hundreds of disconnects and reconnects above) [22:00:26] liangent: once the divs match up to an element in the DOM, the content between the divs is a subtree [22:00:48] liangent: we set RDFa attributes on the root element(s) to mark template-affected content [22:00:52] I mean, how are they displayed to users in VE [22:01:13] oh, it would not be editable normally [22:01:47] except for (maybe, later) rendered template parameters [22:02:07] so on editing of the template itself [22:02:24] s/on/no/ [22:02:55] what about text between them? [22:03:46] if it does not end up in the DOM subtree, it will be a sibling that is also marked up with attributes [22:04:35] eg. in [[Template:H]]:

aaa

, [[Template:F]]:

, [[Page]]: {{H}}bbb{{F}} [22:05:19] 1. will aaa be editable? 2. will bbb be so? 3. can users see aaa and bbb wrapped in a red dotted box? [22:05:32] none of the template output would be editable [22:05:49] all text content will be wrapped in spans with RDFa attributes set [22:05:58] liangent, do you mean editing of the templates source H? or th epage where H is included? [22:06:04] liangent: http://www.mediawiki.org/wiki/Parsoid/RDFa_vocabulary#Template_content [22:06:13] or did i misunderstand this? [22:06:36] we don't target editing of templates themselves, only content pages [22:07:16] so only bbb is editable. and what about question #3 [22:07:54] liangent: bbb would not be editable either [22:08:10] since it ended up in a DOM subtree that was constructed from template output [22:08:35] so the entire div would be rendered in a way that makes it clear that it is not editable [22:08:43] that is up to the VE folks though [22:10:33] then

000

still whole thing uneditable? [22:10:56] because a template call pollute a whole dom tree [22:12:09] we *might* be able to relax that restriction for attribute-only templates [22:12:49] for anything else it will be very hard to figure out which bits of the DOM subtree should be editable and which not [22:13:15] so for now we at least try to reliably protect those parts to avoid any damage [22:13:37] things would be much easier if templates were properly nested [22:13:45] hopefully we'll get there one day.. [22:14:22] liangent gwicke can correct me but this first pass is to support common usage and make VE usable in a large set of use cases and then go about attacking the edge cases. [22:15:51] gwicke: in my template coding practice I always think it's a two step parsing, so as long as the results of template expansion is valid {{-free wikitext, it's ok [22:16:34] and when necessary, escape everything for the second step with {{!}}, {{!((}}, {{((}} etc [22:16:54] liangent: I would definitely recommend not to rely on two step parsing to future-proof your templates [22:21:04] gwicke: but at least sometimes I have to do this to workaround template limits [22:21:45] liangent: you mean depth and size limits? [22:21:53] or functional limitations? [22:22:05] gwicke: depth&size [22:23:30] those are not really set in stone, especially not with a different parser [22:24:06] the depth limit for example is there because PHP + xdebug only supports a stack depth of around 100 calls [22:24:30] 40-50 calls with xdebug activated [22:25:32] btw we have some pages with "depth overflow" warning on page but I can't find anything wrong on it [22:25:53] "warning": being categorized in the category [22:26:16] does the ee-prototype still require autoconfirmed for using the curation bar? [22:26:19] kaldari ^ [22:27:08] lemme check... [22:27:19] I've changed it about 15 times :) [22:27:47] pretty sure not, I was just in there, and I'm not autoconfirmed [22:28:27] liangent: some of those issues might be fixed with Lua templates [22:28:29] anyone should be able to use it as long as you are logged in [22:30:20] gwicke: Lua and VE, which will come earlier? [22:30:54] liangent: I guess Lua [22:31:09] we want to deploy to enwiki in some form by December [22:32:28] in the worst case that might still be a restricted namespace similar to the current mw.org sandbox, but we are working on supporting more than that [22:35:53] what's the current blocker to deploy it on the cluster [22:43:05] liangent: right now we would not gain much by giving it wider exposure [22:43:29] liangent: technical users who know how to report bugs find it on mw.org already [22:44:05] and we have more than enough to do already, the fine tuning will come later [22:44:32] Reedy: about to sync that config change if it's cool with you, will also pick up your Echo config change (or whoever did that one) if it hasn't gone out yet. [22:44:46] Oh, I forgot to commit it [22:44:58] but I've already sync'd it so should be fine [22:45:02] ok [22:45:30] I'll let you do the commit for it [22:46:14] Done [22:46:19] feel free to sync now :) [22:47:57] syncing [23:17:24] kaldari: Around? What's the status of PageTriage & RL fix on your end? I just finished an interview and I'm ready to backport the RL fix to enwiki if you're around to test it [23:17:34] I'm here [23:17:42] Alright [23:17:45] curation toolbar is turned on on testwiki now and is working great [23:17:48] Awesoem [23:18:28] * Danny_B|backup is going to take a look [23:18:45] Deploying a VE fix now, the RL fix is next [23:19:05] I added a new global config var to InitialiseSettings that we can use: https://gerrit.wikimedia.org/r/#/c/18054/1/wmf-config/InitialiseSettings.php [23:19:15] Cool [23:19:26] kaldari: where can i spot it? [23:20:06] go to Special:NewPageFeed and click one of the Review buttons [23:20:10] on test.wiki [23:20:15] you have to be logged in [23:20:23] er Special:NewPagesFeed [23:20:25] sorry [23:21:34] that's that grey thingy on right? [23:22:36] OK deploying RL fix now [23:22:54] Done; will take 5-10 mins to take effect [23:23:17] kaldari: is it going to have tooltips? [23:23:43] eventually [23:24:11] i was afraid to push the buttons which don't have obvious pictogram [23:24:12] Danny_B|backup: yes, the grey thingy :) [23:24:43] the tooltips are actually done, but not merged yet [23:24:55] should have tooltips on Thursday :) [23:25:12] is it configurable? [23:25:21] yes, very configurable [23:25:59] so it should be portable to other wikis once all the bugs are worked out [23:26:01] on wiki or in php settings? [23:26:05] on wiki [23:26:28] i wonder about tags eg. or reasons for deletion [23:26:53] yeah, that can all be configured on wiki for whatever the local templates are [23:27:42] it even supports "multi" tag templates [23:28:19] and all different kinds of tag parameters [23:28:26] it's a beast [23:30:31] RoanKattouw: We don't actually want to turn on Curation Toolbar on en.wiki until Thursday, but it's good to go ahead and have the RL fix in place and tested on test. [23:30:50] OK [23:31:39] I could turn it on briefly and then back off, or hack something up so it only turns on for you; whatever you want [23:31:44] or just leave it be till Thursday [23:33:36] why the review button opens in new window without notifying users? that's against basics web creation guidelines :-/ [23:36:32] don't look at me. i argued against it. [23:37:31] Danny_B|backup: Which review button? Gerrit? [23:37:55] you're my man, jorm, you know it [23:38:09] marktraceur: no, in new pages feed [23:53:27] kaldari: suggestion: clicking on "Curation toolbar" in sidebar when the bar is shown should hide it