[02:49:34] <dr0ptp4kt>	 coreyfloyd: sorry, just saw your irc message. thanks for joining and waiting and joining :) i'm gonna wrap up soon
[13:42:38] <phuedx>	 joakino: yt?
[13:45:46] <joakino>	 phuedx: i'm about to leave to lunch
[13:45:54] <joakino>	 is it quick?
[13:46:14] <phuedx>	 joakino: nope
[13:46:17] <phuedx>	 have a good lunch
[13:46:20] <joakino>	 lol
[13:46:29] <joakino>	 k i'll ping you later phuedx 
[13:46:35] <phuedx>	 later
[15:33:15] <kristenlans>	 romen we have a meet
[15:34:32] <kristenlans>	 rmoen: we have a meet
[16:14:32] <niedzielski>	 dbrant: (correct channel) hey! i had a quick question on some copy for the long press context menu. do you think we should use an ellipsis style to indicate that an action will require further workflow in another screen? for example, tapping "Share page…" would close the current screen and open an activity chooser. it's not something i feel strongly about but i thought it was worthing asking
[16:17:02] <niedzielski>	 dbrant: the next question i has was whether the wording in the overflow menu should match that used in the context window
[16:19:12] <dbrant>	 niedzielski: i don't feel strongly either way myself, but probably leaning more against the ellipsis. Because then, it would raise more questions like, should we use an ellipsis with the "More" item? or "Login"? etc...
[16:20:41] <niedzielski>	 dbrant: ok, i'll leave it out. i didn't know if it was a good windows-ism to bring over or not
[16:22:11] <dbrant>	 niedzielski: but i do agree with making it consistent with the overflow menu. I think it should be "Save page" in both cases... and I'm not sure whether it should be "Share" or "Share page"...
[16:23:52] <niedzielski>	 dbrant: i was struggling with that too. for example, we have "open page" and "open in new tab". if we're being blockheaded consistent, wouldn't it be "open page in current tab" and "open page in new tab"? far too verbose. i think we always want the shortest one that makes sense
[16:24:15] <niedzielski>	 in this case i was wondering if "share page" added a little more context that might make folks feel more comfortable
[16:27:36] <dbrant>	 niedzielski: let's go with "Share page" in both cases, and then let Vibha cast the deciding vote at design signoff.
[16:27:54] <niedzielski>	 dbrant: will do, thanks
[17:04:46] <kristenlans>	 jdlrobson: standup?
[17:08:38] <niedzielski>	 bearND: i'm going to +2 this guy if that's cool with you https://gerrit.wikimedia.org/r/#/c/229263/1
[17:08:59] <bearND>	 niedzielski: thank you
[17:09:54] <niedzielski>	 bearND: er, i was but actually i don't have +2 access on either of my accounts for this repo
[17:10:58] <dbrant>	 i can...
[17:11:34] <bearND>	 niedzielski: ohh, not good. We should get you and mdholloway access somehow
[17:11:54] <bearND>	 dbrant: Did you create this repo?
[17:12:28] <bearND>	 would be good if we gave the same +2 list as for the other android repos
[17:12:52] <dbrant>	 bearND: I think I asked for it to be created... I don't recall setting any permissions on it myself
[17:14:15] <bearND>	 dbrant: do you remember who you asked or who one would ask nowadays?
[17:14:54] <niedzielski>	 bearND: since i just got twn access, do you mind if i try to do a sync now?
[17:15:35] <bearND>	 niedzielski: wow, congrats! I didn't know. Please go ahead
[17:15:47] <bearND>	 sync away
[17:16:03] <niedzielski>	 bearND: sounds good, thnaks
[17:16:12] <bearND>	 niedzielski: first you need to run the one time setup piece
[17:16:39] <bearND>	 niedzielski: let me know if anything is unclear in the doc, and we'll update it
[17:16:45] <niedzielski>	 bearND: will do, thanks
[17:17:10] <dbrant>	 bearND: iirc, there was a Wiki page where you sign up your project to receive its own repo, then someone sets it up for you, and you get a notification.
[17:17:23] <dbrant>	 bearND: but that was almost a year ago
[17:19:34] <jdlrobson>	 fyi joakino new bug - https://phabricator.wikimedia.org/T108204
[17:20:16] <dbrant>	 niedzielski: can you see if you have access to merge it now?
[17:21:37] <niedzielski>	 dbrant: no change :|
[17:22:35] <rmoen>	 jdlrobson, kristenlans, joakino, bmansurov: Sorry guys for missing the meeting this morning.  I totally misunderstood the meeting title
[17:25:37] <joakino>	 thanks jdlrobson, added unbreak prio
[17:31:27] <dbrant>	 niedzielski: now?
[17:31:39] <niedzielski>	 dbrant: yep!
[17:33:55] <dbrant>	 niedzielski: i think you need to Verify+2 on that repo, too
[17:34:25] <bearND>	 dbrant: Thank you. Let us know how you did it.
[17:34:49] <niedzielski>	 dbrant: ok, hopefully good 2 go
[17:35:19] <dbrant>	 bearND|afk: niedzielski: I added the ldap group to have +2 access.
[17:36:19] <bmansurov>	 phuedx: when is a good time to chat about the continuation parameter? https://phabricator.wikimedia.org/T101453
[17:36:23] <dbrant>	 niedzielski: did you click "Submit"? ;)
[17:37:20] <niedzielski>	 details, details
[17:37:25] <niedzielski>	 when i was a kid, a green checkbox meant something
[17:38:09] <niedzielski>	 dbrant: ok, it is written that the change has been merged
[17:38:21] <dbrant>	 niedzielski: o/
[17:50:34] <niedzielski>	 bearND|afk: it looks like the twn sync still expects the output to drop into wikipedia/res/values. i poked around in some of the scripts and hit a deadend in /home/betawiki/config/bin/repoexport. should i ping nikerabbit?
[17:52:09] <niedzielski>	 bearND|afk: it could also be my setup. none of the initialization steps worked for me. i ended up copying REPOCONF from your home directory and running repoupdate wikipedia-android and so forth from my home which seems to work properly.
[18:03:21] <codezee>	 jdlrobson: there?
[18:03:54] <jdlrobson>	 codezee: yup
[18:03:57] <jdlrobson>	 how are you
[18:04:33] <codezee>	 jdlrobson: Good! I've left a comment on https://gerrit.wikimedia.org/r/#/c/228813/ Let me know the final word on that.
[18:05:16] <jdlrobson>	 codezee: let me take a look now
[18:05:53] <jdlrobson>	 codezee: I see.
[18:05:57] <jdlrobson>	 mm
[18:07:34] <jdlrobson>	 codezee: okay that makes sense with min-height i guess for time being - we'll have to think that some more. Definitely worth talking to Nicolas about to see if it's worth reconsidering those banner resolutions with mobile in mind
[18:08:09] <jdlrobson>	 codezee: just optimise it for banners such as Albert Einstein to optimise for the general use case (even though they are not using them now it will be good to showcase what we can do if they do)
[18:09:39] <jdlrobson>	 codezee: sound good?
[18:10:11] <codezee>	 jdlrobson: I guess you mean keep the min-height at 100px and add some js to manipulate it for images with a different aspect ratio?
[18:10:55] <jdlrobson>	 codezee: "define a max-height or a height to .wpb-topbanner (the container) as well."
[18:11:09] <jdlrobson>	 try Einstein_1921_by_F_Schmutzer_-_restoration.jpg as an example
[18:11:57] <codezee>	 ok
[18:15:19] <rmoen>	 jdlrobson: how do I reproduce https://phabricator.wikimedia.org/T108204 ? 
[18:15:54] <jdlrobson>	 Visit beta labs, see that the last modified bar is just a history link. Run that code, see that the message updates and it has a profile and history link
[18:17:00] <rmoen>	 ah ok
[18:17:02] <rmoen>	 ty
[18:18:09] <rmoen>	 jdlrobson: interesting seems to be working locally. 
[18:18:20] <rmoen>	 I do see the issue on beta labs
[18:18:49] <jdlrobson>	 it's broken for me locally. Stable running latest core code
[18:19:19] <rmoen>	 Hmm yeah i'm fully updated.  There are js errors on the beta page http://en.m.wikipedia.beta.wmflabs.org/wiki/Alcatraz_Island
[18:21:55] <rmoen>	 jdlrobson: oh ok there we go. 
[18:24:07] <phuedx>	 bmansurov: you said that i might be able to help with something?
[18:24:11] <phuedx>	 sorry, my brain's fuzzy
[18:25:39] <bmansurov>	 phuedx: yes, let me find the code
[18:26:20] <bmansurov>	 phuedx: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/resources/mobile.watchlist/WatchListApi.js#L25 
[18:26:30] <bmansurov>	 phuedx: where can I read up on '-||' ?
[18:28:11] <phuedx>	 bmansurov: sec -- tracking down the ticet
[18:28:13] <phuedx>	 task
[18:29:17] <bmansurov>	 phuedx: https://gerrit.wikimedia.org/r/#/c/210679/
[18:29:52] <phuedx>	 bmansurov: associated epic: https://phabricator.wikimedia.org/T96858, new continue format: https://www.mediawiki.org/wiki/API:Query#Continuing_queries, old continue format: https://www.mediawiki.org/wiki/API:Raw_query_continue
[18:29:53] <jdlrobson>	 rmoen: i'd suggest talking to Krinkle_ to understand how the async js broke it. I have a feeling global inline events will not work anymore
[18:31:29] <rmoen>	 jdlrobson: so i see the issue,  in MinervaTemplate.php we are inline emitting history-link-loaded which is before the module is loaded.    Can't we just initHistoryLink in the mobile.head/init.js ? Doing it this way there is a split second where the original text is visible.  Are we trying to avoid this ? 
[18:31:31] <bmansurov>	 phuedx: thanks
[18:32:03] <jdlrobson>	 rmoen: the purpose is to minimise flash of unstyled content to our user
[18:32:08] <phuedx>	 bmansurov: don't thank me, i should've at least included a link in the comment
[18:32:10] <jdlrobson>	 as the change can be jarring (it can go green for example)
[18:32:22] <phuedx>	 it's an innocuous little string that means quite a lot
[18:32:23] <rmoen>	 jdlrobson: i see
[18:32:25] <phuedx>	 ;)
[18:32:31] <jdlrobson>	 and split second is much longer on 2g connection :)
[18:32:45] <rmoen>	 Can we top load the mobile.head module ? 
[18:33:23] <jdlrobson>	 it __is__ top loaded but now not blocking
[18:33:38] <jdlrobson>	 the script is async now
[18:35:19] <rmoen>	 Right.  Well, Since its loading async i'm not quite sure how to avoid the noticeable style changes
[18:36:11] <phuedx>	 what's the difference between the dom without the script executing and with?
[18:37:29] <phuedx>	 wait… maybe i'm confused
[18:37:36] <rmoen>	 phuedx: with the inline script there is no difference in the dom as the emit is happening prior to the module.  If I'm understanding your question correctly
[18:37:38] <phuedx>	 yep… i'm confused
[18:38:02] <phuedx>	 rmoen: yup -- i got there eventually ;)
[18:38:08] <rmoen>	 it would be *nice* if our event emitter would re-emit once a module is present... 
[18:38:40] <rmoen>	 but the way we are doing it in MinervaTemplate.php is a total hack and shouldn't be the solution 
[18:39:29] <rmoen>	 I'm suggesting we tear that part out, and just run the last modified behavior when the module is loaded.  Flashing or not, at least its modified
[18:40:46] <Krinkle>	 jdlrobson: rmoen: Inline scripts, while discouraged for awhile now, are still supported. However it was never supported to manually construct <script> tags directly. Always use the ResourceLoader class as abstraction so that you don't have to stay in sync everytime it changes.
[18:41:04] <Krinkle>	 In this case, it has to use RLQ instead of if(window.mw) which no longer works. 
[18:41:20] <Krinkle>	 Use ResourceLoader::makeInlineScript
[18:41:38] <Krinkle>	 That used to create <script>if(window.mw) and now makes <script>RLQ.push(function () { instead.
[18:41:50] <rmoen>	 jdlrobson: I wonder if this is affecting header-loaded also, which registers the click events
[18:42:02] <Krinkle>	 If you need any additional conditions (it looks like you have a cond on 'mw.mobileFrontend') put that inside of it as you would otherwise
[18:43:52] <rmoen>	 Krinkle: Thanks for jumping in. Will look at ResourceLoader::makeInlineScript
[18:48:58] <phuedx>	 rmoen: visibility: hidden – preserving bounding rect – visibility: visible when the script has loaded, no flash/no reflow ?
[18:49:29] <rmoen>	 phuedx: that sir is a great idea
[18:51:21] <phuedx>	 you're right -- the current solution is hacky
[18:53:57] <dbrant>	 etonkovidova: the Android QA column is calling your name :)
[18:54:44] <etonkovidova>	 dbrant: absolutely! :) Thx  - will be working exclusively today on it 
[18:56:04] <phuedx>	 okie poke
[18:56:07] <phuedx>	 g'night folks
[19:38:19] <bearND>	 niedzielski: good point. The repo folder change is to blame. Would you like to update https://git.wikimedia.org/blob/translatewiki/48f2c0ee5ce37db3476ebe84c90c3a43a625aae7/groups%2FWikimedia%2FWikimediaMobile-android.yaml#L231 and the next line, too?
[19:39:19] <bearND>	 niedzielski: I added a link to the repo at the bottom of https://www.mediawiki.org/wiki/Translation_of_app_string_resources#Translatewiki_on_Gerrit
[19:39:21] <niedzielski>	 bearND: sounds good
[19:41:08] <bearND>	 niedzielski: In the last couple of month I did not use REPOCONF from my home dir. Instead of that, I switched over to using /resources/bsitzmann
[19:41:27] <niedzielski>	 bearND: any reason why? i don't evem have perms in that dir
[19:41:33] <niedzielski>	 write perms*
[19:41:41] <bearND>	 niedzielski: I probably should have deleted the stuff in my home dir there
[19:42:14] <bearND>	 niedzielski: Siebrand set it up for me. You should ping him or Nikerabbit to create a folder for you
[19:44:54] <bearND>	 niedzielski: I don't know what the advantage of /resources folder is. That's just how he set it up.
[19:49:09] <jdlrobson>	 phuedx|afk: we need to decide what to do about the `dev` branch. Currently none of our repositories are pointing to it. We'll need to communicate what we're doing to other teams and why etc.. and when and how things get picked to master. What would be willing to write that up?
[19:53:06] <niedzielski>	 bearND: it's been interesting to see all the places that a directory change has affect. the app itself, all the app scripts, the alpha script (separate repo), and the twn config (separate repo), IIRC
[19:58:53] <bearND>	 niedzielski: a lot of places, but surprisingly not Jenkins
[19:58:57] <kaity>	 joakino: hey are you available to meet for design review?
[19:59:11] <joakino>	 kaity: ye
[20:32:24] <bmansurov>	 MaxSem: you got a sec to answer a question about api.php?
[20:32:36] <MaxSem>	 sure
[20:32:49] <bmansurov>	 MaxSem: thanks, here is a write up https://phabricator.wikimedia.org/P1846
[20:34:54] <MaxSem>	 why do you start with &gwrcontinue=0%7C2 ?
[20:35:22] <bmansurov>	 otherwise I get a warning that I should pass empty continue
[20:35:43] <MaxSem>	 remove that parameter completely
[20:35:58] <MaxSem>	 just empty continue
[20:36:18] <bmansurov>	 hmm
[20:37:13] <etonkovidova>	 dbrant: I got many org.wikipedia.alpha W/BottomContentHandler﹕ Error while fetching Read More titles. for 2.0.108-alpha
[20:37:30] <bmansurov>	 MaxSem: updated the paste with a comment
[20:37:34] <etonkovidova>	 dbrant: it's a known error?
[20:38:49] <bmansurov>	 MaxSem: sorry, I forgot, I need that to load watchlist items starting a certain page
[20:39:22] <bmansurov>	 MaxSem: so I don't want to load the first batch of watchlist items because they are loaded in the backend, I'm trying to get the next batch with my first query
[20:39:37] <etonkovidova>	 dbrant: seems like the server is down...
[20:40:03] <dbrant>	 etonkovidova: hmm, haven't seen that! is it a crash, or just a message that appears?
[20:40:21] <MaxSem>	 oh, heh - we're having problems in prod
[20:41:09] <etonkovidova>	 MaxSem: dbrant - hmm... seems to be back to normal again 
[20:41:19] <etonkovidova>	 dbrant: was 503 error
[20:41:30] <MaxSem>	 etonkovidova, prod problems
[20:42:03] <dbrant>	 etonkovidova: ah, now I'm seeing server errors. Just want to make sure we don't crash in these situations.
[20:48:31] <etonkovidova>	 dbrant: seems back to normal now ...
[20:56:51] <bearND>	 etonkovidova: dbrant: sounds like the error handling changes are starting to pay off
[20:57:58] <dbrant>	 :D
[20:58:33] <etonkovidova>	 bearND: yup - and also it's so much more entertaining to watch logcat :)
[21:11:40] <rmoen>	 jdlrobson: ty for merge :)
[21:11:46] <MaxSem>	 back from hell breaking loose. bmansurov, instead of wrcontinue you should use wrfromtitle
[21:11:59] <bmansurov>	 MaxSem: I did ;)
[21:12:23] <bmansurov>	 MaxSem: jon suggested that using formatversion=2 may help it looks like it does
[21:12:38] <jdlrobson>	 kaity: feedback for https://phabricator.wikimedia.org/T98029 needed :)
[21:12:52] <jdlrobson>	 and https://phabricator.wikimedia.org/T107603
[21:25:49] <FlorianSW>	 jdlrobson: I remember there was a testing instance for WikidataPageImages, does it still exist? Can you give me the url? Want to see how it looks in the very latest version without setting it up locally :]
[21:27:08] <jdlrobson>	 http://pagebanner.wmflabs.org/wiki/Main_Page :)
[21:27:16] <jdlrobson>	 doh codezee just stepped out
[21:27:25] <jdlrobson>	 i'm not sure how up to date it is
[21:27:50] <jdlrobson>	 the banner positioning looks promising. See http://pagebanner.wmflabs.org/wiki/Agra
[21:28:52] <bmansurov>	 looks good ^
[21:38:39] <kaity>	 jdlrobson: thanks I'll check it out
[21:40:51] <etonkovidova>	 dbrant: regarding:  https://phabricator.wikimedia.org/T104623 - Add event logging funnel for navigation menu interaction
[21:41:08] <etonkovidova>	 dbrant: can it be actually seen, say, on http://mobile-reportcard.wmflabs.org/ or something?
[21:41:54] <dbrant>	 etonkovidova: unfortunately, no... it can only be seen via the eventlogging server (stat1003)
[21:42:14] <etonkovidova>	 dbrant: ok ...
[21:52:22] <FlorianSW>	 jdlrobson: that's awesome! \o/ great GSoC project.
[21:54:38] <jdlrobson>	 FlorianSW: yeh i'm excited to see it live and used
[21:55:53] <FlorianSW>	 jdlrobson: if there were such banner images for every wiki article, it would be very interesting to have this on wikipedia, too :) Images compared with informational text are awesome!
[22:00:06] <jdlrobson>	 FlorianSW: i can't find the bug but i'm sure it was the toast :)
[22:00:34] <jdlrobson>	 FlorianSW: i think the apps could use this for storage potentially at some point with a parsoid api
[22:00:48] <jdlrobson>	 and save focus areas
[22:01:48] <FlorianSW>	 jdlrobson: can you remember, if we fixed that bug? I think we have?!
[22:02:04] <FlorianSW>	 your two other messages are realted to the wikidatapageimages extension, right? *confused* :P
[22:02:36] <jdlrobson>	 https://phabricator.wikimedia.org/T98282 < FlorianSW  :)
[22:02:40] <jdlrobson>	 FlorianSW: yes sorry
[22:02:43] <jdlrobson>	 :)
[22:02:50] <jdlrobson>	 i'm very confusing :)
[22:02:52] <FlorianSW>	 no worries, it's late for me, not for you :P
[22:04:29] <FlorianSW>	 jdlrobson: ah, ok, but T98282 is visible, the one I filed isn't visible, it's "just" rendered :)
[22:04:42] <FlorianSW>	 is -> was
[22:04:50] <jdlrobson>	 :-) all is good FlorianSW just that's what i was remembering 
[22:05:47] <FlorianSW>	 but I remember, that we had a similar thing with rendering a module which isn't used in Lyon, iirc with ori tracked it down
[22:14:47] <jdlrobson>	 brb i need to grab some coffee i'm struggling this afternoon ;-)
[22:18:15] <etonkovidova>	 dbrant: a question again :) 'Read more' for Main page - what it's supposed to suggest? 
[22:18:52] <dbrant>	 etonkovidova: it's based on the last item that's in your History (that isn't the main page).
[22:19:35] <etonkovidova>	 dbrant: and I thought it's a bug :) Ok.
[22:34:36] <rmoen>	 jdlrobson,  so https://gerrit.wikimedia.org/r/#/c/229412/ didn't merge yet and i'm sure i have a conflict now because i based the config off the version before you rolled back
[22:34:48] <rmoen>	 so it can be resolved later i suppose, just a heads up
[22:36:18] <rmoen>	 jdlrobson: also you should note that i've got an example config here.  https://gerrit.wikimedia.org/r/#/c/229989/ since you are working on showing a configured survey.
[22:36:37] <rmoen>	 brb
[23:37:51] <bd808>	 a pox on you jdlrobson for adding me to a paladox patch
[23:38:07] <jdlrobson>	 a pox? :)
[23:38:14] <jdlrobson>	 how comessss?
[23:38:25] <bd808>	 Patch Set 67
[23:38:53] <jdlrobson>	 i know :( i'm keen to wrap this up. There's been lots of confusion, concerns, rebasing.
[23:39:12] <bd808>	 he's like that on every patch he ever makes
[23:39:30] <bd808>	 so what are you trying to figure out now?
[23:39:41] <bd808>	 how to document legoktm's json entry point?
[23:39:58] <legoktm>	 hmm?
[23:40:18] <bd808>	 legoktm: jdlrobson has some sort of question about https://gerrit.wikimedia.org/r/#/c/209882/
[23:41:55] <jdlrobson>	 So i'm keen to get that albatross neck patch merged. The main issues are around documenting the json. In this patch it has been moved into https://gerrit.wikimedia.org/r/#/c/209882/68/README.md but i know for a fact that would be neglected.
[23:42:20] <jdlrobson>	 So I guess the question is has someone solved this problem, and if so is there an example I can point paladox to
[23:42:54] <jdlrobson>	 I remember something about adding '@doc' keys
[23:43:02] <legoktm>	 does it even work? 
[23:43:12] <jdlrobson>	 i haven't got that far ;-)
[23:44:14] <legoktm>	 no it doesn't
[23:44:16] <legoktm>	 sigh.
[23:44:56] * bd808 quietly removes himself from the patch
[23:45:05] <jdlrobson>	 legoktm: if you can help me solve the doc problem i'll take it the rest of the way
[23:45:21] <legoktm>	 what is the doc problem?
[23:45:34] <legoktm>	 there's https://www.mediawiki.org/wiki/Manual:Extension_registration#Retaining_documentation
[23:48:49] <bd808>	 I think the big thing here is that mobilefe is more like an app stack than an extension. too many knobs and switches
[23:49:47] <jdlrobson>	 bd808: yeh and we're trying to dissassemble that piece by piece ... a lot of things need changes in core to support which are sometimes hard to get buy in.
[23:50:28] <bd808>	 jdlrobson: oh I know it's being worked on and thank you! I was just explaining the difficulty in the current state
[23:50:38] <jdlrobson>	 So legoktm is acceptable to do something like this:
[23:50:43] <jdlrobson>	 https://www.irccloud.com/pastebin/xkjOhmdL/
[23:50:52] <jdlrobson>	 cos technically same name keys are okay in json
[23:50:54] <jdlrobson>	 but it feels icky
[23:51:04] <legoktm>	 yes
[23:51:14] <jdlrobson>	 that's essentially what we need though whilst things are in the unfortunate state they are..
[23:51:19] <legoktm>	 it is icky, using a free-format README file is a better idea IMO
[23:51:24] <legoktm>	 or on-wiki
[23:51:28] <jdlrobson>	 i just know it won't get updated
[23:51:35] <jdlrobson>	 i just have to take a look at Extension:MobileFrontend
[23:52:09] <bd808>	 jdlrobson: it will get update if you make it part of your Definition of Done ;)
[23:53:10] <legoktm>	 that's the responsibility of the reviewers to make sure docs stay up to date.
[23:53:16] <jdlrobson>	 i dunno.. there's just too many places.. Readme's, all sorts of wiki's... my general feel on this thing is documentation should be generated from the code itself and the documentation should be as close to the code as possible. I've solved this for js documentation in mobile - jenkins complains if you don't document
[23:53:26] <jdlrobson>	 not sure how to apply that to other things (uses jscsdoc)
[23:53:47] <legoktm>	 in the future all configuration settings will be documented as i18n strings. Soon(TM).
[23:53:54] <jdlrobson>	 that would be great
[23:54:21] <jdlrobson>	 okay.. I think the icky https://www.irccloud.com/pastebin/xkjOhmdL/ is the way forward though for the time being
[23:54:30] <jdlrobson>	 i'm keen to get us extension.json-ified
[23:54:44] <bd808>	 why?
[23:55:33] <jdlrobson>	 from what i understand from Toby there are performance benefits to be had?
[23:55:39] <jdlrobson>	 you don't think we should?
[23:56:01] <bd808>	 there will be some perf benefits once everything it switched
[23:56:15] <bd808>	 but if it's a struggle... why bother yet
[23:56:21] <jdlrobson>	 so i'm part of the problem... and i don't like being part of the problem :)
[23:56:29] <bd808>	 Kunal may have a different opinion
[23:56:59] <jdlrobson>	 anyway this patch ain't going away till i merge it ;-)
[23:57:07] <legoktm>	 converting the bigger extensions first usually exposes lots of bugs in extension registration...which is good :P
[23:57:14] <legoktm>	 I found one due to MF just now
[23:57:30] <legoktm>	 VE found 3 or 4 so far
[23:59:17] <legoktm>	 I'm not really pushing conversion anymore, people have started doing it on their own now without me nagging them :-)
[23:59:27] <legoktm>	 but converting MF is a good idea :)
[23:59:35] <James_F>	 legoktm: Hopefully you found all of them in VE, given we removed all the contents of VisualEditor.php some times ago. :-)