[17:04:30] greetings all [17:04:59] awjr: jdlrobson yuvipanda : ready to meet ? [17:05:05] MaxSem|away won't be joining us [17:05:07] tfinc: yup! [17:05:13] tfinc: can you give me 3 minutes? [17:05:29] k [17:05:47] i can but im very confused by time zone maths :) [17:05:59] jdlrobson: they never make sense to me [17:06:10] i make it 5PM GMT [17:06:45] 3pm, atm, innit? [17:06:53] my IRC client is stuck in GMT so always have a good handle on jdlrobson's timeline [17:07:02] well today im on GMT+1 [17:07:04] :P [17:07:05] + I seem to have a mostly working internal PST convertor in my head [17:07:08] God damn DST [17:07:30] awjr: you ready? [17:07:37] luckily im back to take away 8 hours next weekend [17:07:45] tfinc yes [17:07:56] thanks for waiting [17:17:36] jdlrobson: do you want to chat in a bit about the contact page stuff? [17:18:02] yes [17:18:21] also what time do you want to start deployment process so i can make sure i organise food around it? [17:19:02] jdlrobson: let's meet at 1030am PDT to discuss contact page stuff and we can meet again at 1pm PDT to review deployment stuff. sound ok? [17:19:42] * jdlrobson checks how time works [17:20:00] so contact in 10mins? [17:20:33] yup [17:20:51] i need to go make some coffee :p [17:21:29] ok [17:21:54] i have to break in 40mins though for budget planning [17:22:06] so you'll have me for 30mins [17:22:48] there were contact page revisions that phil asked for that i have not finished, if that affects your chat at all. [17:25:28] jdlrobson: ok im ready when you are [17:26:08] tfinc, preilly: asher mentioned he should be able to get the squid changes out before our deployment today [17:27:14] heatherw i think at this stage it's more about what needs to change on the server rather than design but will let you know! [17:27:28] awjr yeh im ready how did you want to do this? on irc good? [17:27:37] irc is great jdlrobson [17:27:40] cool [17:27:53] so basically I've interpreted http://www.mediawiki.org/wiki/Mobile_design/Contact as a redesign of the feedback page [17:27:57] can you send me a link to the mockups? i am having trouble locating it [17:27:58] oh [17:27:59] nm [17:28:01] cool! thanks [17:28:02] as I don't see any reason why they wouldn't be the same [17:28:21] in which case it should be just altering what is stored [17:28:37] (so currently it asks for a subject http://en.m.wikipedia.org/w/index.php?title=Main_Page&useformat=mobile&mobileaction=leave_feedback [17:28:41] and the new mockup has email [17:28:47] and a couple of other options [17:29:05] jdlrobson i had a chat with philinje last week about this stuff and there are a few gotchas with this iteration of the contact page [17:29:15] ok hit me with them [17:29:39] the big weird tone is what happens if someone selects 'artice feedback - factual error' [17:29:44] s/tone/one [17:30:24] instead of providing a comment box/sending an email to someone, they are supposed to be redirected to the factual error page for the particular project they are on [17:30:56] i think there is yet to be a decision made on how to handle the experience (eg do we automatically redirect the user, just display a link, or both with a time delay on the redirect to give them the chance to bail) [17:31:02] i don't think i ever got a response about this: [17:31:03] 17 05:23:38 < jeremyb> any recent news about mistaken redirects from normal project URLs to mobile in non-mobile browsers? (and a non-working disable mobile button) [17:31:06] 17 05:23:54 < jeremyb> i know it was an issue a couple months ago. but we just got a brand new OTRS ticket about it: 2012031710000869 [17:31:09] 17 05:24:30 < jeremyb> it doesn't say explicitly that it's a desktop browser but i think so [17:31:22] but the other gotcha about this is that the 'factual error' page is different for each of the projects [17:31:34] we also got a ticket from a different person on an iPhone. that's 2012031910000696 [17:31:45] jdlrobson: and im concerned it might be different for sub-projects as well [17:32:05] i see [17:32:08] yeh it's a bit unexpected [17:32:16] please hilight me if you respond [17:32:18] so for instance on en wikipedia the user would go to: http://en.wikipedia.org/wiki/Wikipedia:Contact_us/Article_problem/Factual_error [17:32:21] * jeremyb heads off for a bit [17:32:32] but for es.wikipedia.org that does not exist: http://es.wikipedia.org/wiki/Wikipedia:Contact_us/Article_problem/Factual_error [17:32:34] awjr: when philinje and i last talked, it was redirected time delay with a button to go forward [17:32:47] heatherw: ok cool thanks! [17:33:09] so jdlrobson, we need to figure out what to do about that [17:33:25] yeh that's incomplete - imo what should happen is that when selecting factual error you'd get some feedback linking to this page [17:33:53] well, i think regardless we need to figure out what /all/ of the links are supposed to be [17:33:54] but to be honest if someone is using the contact page for this purpose it sounds like they don't understand what wikipedia is - and i would have thought it would be good to record their feedback on the talk page or something? [17:34:08] well we can descope that for the time being right by not providing it in the drop down? [17:34:48] i am certainly open to that if it's cool with tfinc and philinje [17:34:52] awjr: jdlrobson : heads up if any part of the contact us is unclear then do let philinje know. we can also reach out to phillippe as he helped to craft this [17:35:10] i think we should descope it and record this on the talk page [17:35:17] (which I can do) [17:35:24] tfinc jdlrobson, i brought this up with philinje last week as well but we didn't really have a conclusive answer of what to do [17:36:17] jdlrobson: ok sounds good for now, that will certainly make life easier. in the long run, someone's going to have to either come up with a list of what all of those links should be for every single project, or we'll have to devise some other way to automatically determine what that link should be [17:36:19] awjr tfinc: we could make it so that Article feedback - factual error sends the email but doesn't do anything more [17:36:22] yuvipanda: are we still on track for a thursday market push ? [17:36:35] at least that way we won't get people using general for that sort of stuff [17:36:39] philinje: can you help out jdlrobson and awjr ? [17:36:47] tfinc: i'll know by EOD today. [17:36:56] k [17:37:25] jdlrobson: out of the new ui/features that you've been working on .. which ones are likely to go today? [17:37:36] jdlrobson: i think the problem is that 'factual error' is a common thing people want to comment about - they probably want to use the FAQ link to prevent OTRS spam because it's such a common thing that we can't really do anything about, [17:37:36] references [17:37:42] and the full screen search [17:37:46] (results list without summary) [17:37:51] it's in the release notes [17:37:56] excellent [17:38:01] the other stuff should follow quickly once there is consensus [17:38:07] sweet [17:38:21] im hoping linSmith and heatherw can make a decision on what to do with the toggle buttons (lhs/rhs debate) [17:38:24] jdlrobson, philinje, another thing to double check is that the 'factual error' page is a common thing across all wikis/projects because i have a hunch that it is not [17:38:34] did we get enough consensus about collapsable and expandable sections ? [17:38:46] as i'm not seeing them on the deployment page [17:39:00] jdlrobson: --^ [17:39:18] tfinc ^ : im hoping linSmith and heatherw... [17:39:25] k [17:39:35] the RHS ones are ready to go but keen not to push unless we are 100% happy with them [17:40:00] RHS ? [17:40:23] sorry right hand side [17:40:24] jonrobson.me.uk/wikipedia/ reflects the current state of affairs [17:40:58] (for the record i'd like to push the toggle buttons today if it is at all possible) [17:41:04] jdlrobson: also, because the workflow is not consistent on the contact page, i suggested to philinje that the layout/behavior be slightly modified from what's currently spec'd on mediawiki.org. i dunno what they're going to wind up doing, but if they implement the changes, it will likely create a little more logic work on the front-end (i dont think it will have any back-end implications unless we want to do something fancy with the API) [17:41:14] but the general idea was to initially only display the 'comment category menu' [17:41:31] agreed [17:41:33] and then display the appropriate elements on the page depending on the slected category [17:43:08] awjr - just writing this up [17:44:34] jdlrobson: for the rest of the backend handling i was thinking of trying to use FormSpecialPage for generating the form elements, handling form submission, and the rest of the logic (mailing to the apropriate place, etc) [17:44:54] awjr - http://www.mediawiki.org/wiki/Talk:Mobile_design/Contact [17:45:08] ok so awjr if i give you some html to generate you could do that? [17:45:09] i've not used it before, but it appears to be a subclass of SpecialPage that facilitates form creating/handling [17:45:16] jdlrboson: yup [17:46:09] jdlrobson: thanks for adding that to the talk page [17:46:28] http://pastebin.com/Gj8WAc1A this was my first stab [17:46:42] i think that's all the html I need to style correctly [17:47:05] jdlrboson: ok cool [17:47:43] jdlrobson the other thing that was unclear to me is the 'after sending a comment' functionality [17:48:01] the way it is currently spec'd on mediawiki.org sounds a little bizarre to me - what do you think? [17:48:45] imo it would be better to actually show the user a thank you page rather than populate the text of the 'email' box with 'thank you' etc [17:49:05] agreed [17:49:09] that is very weird [17:50:13] ah the other lingering question for me is [17:50:29] 'this email address: info-XX@wikimedia.org, where XX is one of the language codes listed below' [17:50:41] i think that should read above the email box [17:50:52] we should be able to do all this with ajax anyhow [17:50:55] where do we derive the language code? is it supposed to be the language of the project, or the language in which the user is viewing the project? [17:51:06] (so no need to leave the page) [17:51:14] jdlrobson: for sure [17:51:22] i would guess the language in which the user is viewing the project [17:51:34] i like that better. or to even hide the text input areas and go back to just displaying the category selection box [17:51:39] but my past experience says you'll still get people posting messages in languages different to what they are reading [17:51:47] jdlrobson: yeah [17:52:09] i think what's listed her is OTRS convention so i can probably ask some OTRS-y people to see what they usually do [17:53:15] also do we have to worry about spam? [17:53:23] no recaptchas here.. [17:53:31] ahhahahaha [17:53:46] i dont think we want to get into a recaptcha fight [17:53:52] [WikipediaMobile] brion pushed 2 new commits to master: http://git.io/gtqanA [17:53:52] [WikipediaMobile/master] 144x144 icon for iPad Retina display - Brion Vibber [17:53:52] [WikipediaMobile/master] Merge pull request #177 from brion/icon-ipad3 - Brion Vibber [17:53:54] with the community i mean [17:54:00] ok :) [17:54:05] been there done that [17:54:08] behold my retina display [17:54:08] not fun. [17:54:09] BEHOLD [17:54:11] ! [17:54:18] Project WikipediaMobile - Nightly builds build #241: SUCCESS in 14 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/241/ [17:54:19] * yuvipanda: Actually commit CHANGELOG [17:54:19] * brion: 144x144 icon for iPad Retina display [17:54:26] icon now shinier [17:54:56] jdlrboson: i agree though - but we should probably leave the captcha off until enough people complain about it so we have good reason to implement it [17:55:06] awjr: make them write wikitext. If they succeed, can't be humans :D [17:55:07] * yuvipanda runs [17:55:12] lol [17:56:08] I'm back [17:56:08] jdlrobson: thinking about spam from this is probably a good thing to put on philinje's radar as well if it isn't already [17:56:26] greetings OuKB [17:56:48] awjr, how about simple captcha "type two times two here"? [17:57:18] OuKB: there is actually a catpcha extension for MediaWIki that provides a couple of basic captchas like that [17:57:40] i guess we could implement one of those, but they are easily defeated by robots [17:58:22] I don't think that bots can easily defeat custom QuestyCaptcha questions [17:58:26] awjr: I vote skip the captcha for now. [17:58:50] Yuvipanda: ping [17:58:54] Amgine: pong [17:58:57] from the last time i looked into captcha stuff (admittedly about 1 year ago), the only captcha solution that has proven resistent to bots is reCaptcha [17:59:11] but reCaptcha is very controversial in the wikimedia community [17:59:17] preilly: agreed [17:59:18] Yuvipanda: have an e-mail for you. Forwarding. [17:59:51] Amgine: sure [18:00:15] I thought bots beat reCaptcha easily these days [18:00:24] jdlrobson: yuvipanda : I'm going to dial you in on skype [18:00:25] Asirra ftw. [18:00:42] k awjr i've updated the talk page - will catch up with you after this call [18:00:55] jdlrobson: sounds good. for now i think i have plenty to get started [18:01:05] excellent [18:18:30] yuvipanda is it just me or is the line quite bad? [18:18:44] jdlrobson: just you? :P [18:18:50] having to strain to hear :) [18:19:08] tfinc, so here's my report: finished whole-text extraction, just committed latest fixes. now investigating a fatal on the live site [18:21:03] funniest stuff about that fatal is that it isn't reproduceable even on labs [18:23:52] jdlrobson: are you guys using skype or one of the office conference lines? [18:24:08] awjr: skype [18:25:00] jdlrobson: in my experience the skype audio quality is usually better than the conference lines in the office - but it depends on where the computer is positioned/if there's a mic set up, etc [18:51:20] grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr [18:52:04] can't repro a bug even on testwiki, it surfaces only on en [18:52:39] anyone with shell access who can help? [18:55:18] tfinc: +1 on preilly's idea. [19:00:20] yuvipanda: which idea? [19:00:58] 'experimentation' time. [19:01:08] yup, that makes sense [19:01:13] i'm going to bring that up in tomorrow budget meeting [19:01:25] and see how i can work it in [19:01:40] tfinc +1 also [19:02:03] * tfinc waits for awjr and maxsem to +1 it as well [19:02:07] :) [19:02:23] im sure I could imagine interesting 'apps' that have nothing to do with wikipedia itself but use the api and increase contributions / accuracy [19:02:32] tfinc: ? [19:02:43] awjr: i'll type this up in an email [19:02:45] kk [19:02:52] but one of the topics that came up during the budget meeting [19:03:04] was carving out something similar to 20% time for experimentation [19:03:12] new frameworks, new mobile tech, etc [19:04:26] whyat experimentation time? [19:05:35] time outside of your regular projects to experiment. currently we really don't have that as code review takes our 20% time [19:05:48] preilly brought up a point that he would like more time to play with new technologies [19:06:40] arg. i forgot something at home [19:06:50] need to run their and come back [19:07:14] bbiab [20:07:14] ok .. back [20:07:28] awjr, need your help [20:07:53] OuKB? [20:08:53] OuKB what's up? [20:08:53] https://en.wikipedia.org/w/api.php?action=query&prop=excerpts&format=json&exlimit=10&titles=Barack%20Obama [20:12:20] it isn't reproduceable anywhere else, including http://mobile-geo.wmflabs.org/w/api.php?action=query&prop=excerpts&format=jsonfm&exlimit=10&titles=Barack%20Obama [20:12:20] even with the same text and templates [20:12:20] oops [20:12:20] so I need a debugging hack [20:12:20] jdlrobson: can you wait a few minutes to talk about deployment while i take a quick look at the issue OuKB just brought up? [20:12:20] yep sure [20:12:20] that's fine [20:12:20] i'm troubleshooting a problem myself [20:12:20] kk [20:12:20] i guess MaxSem is not around :( [20:12:20] .me is MaxSem;) [20:12:20] OuKB == Maxem [20:12:20] lolz [20:12:20] awjr, the offending piece of code is http://svn.wikimedia.org/viewvc/mediawiki/branches/wmf/1.19wmf1/extensions/MobileFrontend/MobileFormatter.php?view=markup#l228 [20:12:20] OuKB for a second i thought you might be MZMcBride [20:12:20] my nick isn't girlish:) [20:12:20] lol [20:12:23] ok OuKB i've got a few minutes to help out [20:12:40] http://techblog.netflix.com/2012/03/testing-netflix-on-android.html <-- netflix mobile testing [20:12:59] if ( !$itemToRemoveNode->parentNode) { var_dump($this->doc->saveXML( $itemToRemoveNode->parentNode, LIBXML_NOEMPTYTAG )); die; } [20:13:20] I need something like this^^ between lines 228 and 229 [20:13:24] OuKB you want me to add that on test.wikipedia.org? [20:16:36] it's not reproduceable on test :( [20:16:36] hmm ok if i put that live on enwiki it will be live everywhere. is that going to cause a problem? [20:16:36] I'm not sure what to do with debugging information [20:16:36] we should be able to write that info to a log somewhere without having to var_dump() and die() [20:16:36] but i dont really know how that works on the cluster [20:16:36] lemme see if i can find out [20:16:36] and dump $itemToRemove, too [20:21:20] OuKB - i got info on how to dump to a log file [20:21:37] so we can do something like: [20:22:31] if ( !$itemToRemoveNode->parentNode) { trigger_error( __METHOD__ . ':' print_r( $this->doc->saveXML( $itemToRemoveNode->parentNode, LIBXML_NOEMPTYTAG ), true )); } [20:23:07] or just do that as an else {} on the if ( $itemToRemoveNode ) ? [20:23:13] OuKB ^ [20:23:45] no, $itemToRemoveNode is not null [20:24:03] so there should be a separate check for $itemToRemoveNode->parentNode [20:24:21] inside of if ( $itemToRemoveNode ) [20:24:32] ah ok [20:26:32] OuKB like: http://pastie.org/3630416 [20:27:02] no, you'll have fatal before the check:) [20:27:14] duh [20:27:17] good catch [20:27:17] insert debugging code between 228 and 229 [20:27:52] http://pastie.org/3630430 [20:28:05] OuKB^ [20:28:19] aha [20:30:10] looks good [20:31:43] OuKB ok lemme get this pushed [20:33:29] hmm that didnt appear to work as epxected one sec [20:37:22] preilly: how long would you say its going to take you to puppetize vumi / [20:37:24] ? [20:38:21] OuKB: not going as expected, but tell me if you can get any info from this: https://en.wikipedia.org/w/api.php?action=query&prop=excerpts&format=json&exlimit=10&titles=Barack%20Obama [20:39:40] looking [20:40:52] awjr, can you also dump $itemToRemove ? [20:41:04] in the same place? [20:41:18] OuKB? [20:41:21] tfinc: I'm not sure yet [20:41:35] tfinc: but, I guessing I can probably handle it in a week at most [20:41:51] s/I/I'm [20:42:03] YES [20:42:11] oops, caps [20:42:54] OuKB using doc->SaveXML also? [20:42:58] brion: poke. [20:43:11] no, that var is simply string [20:43:16] awjr, ^ [20:44:07] ok OuKB, same link [20:44:11] https://en.wikipedia.org/w/api.php?action=query&prop=excerpts&format=json&exlimit=10&titles=Barack%20Obama [20:46:17] * OuKB groans [20:46:28] yuvipanda|afk, yo [20:46:35] damn [20:46:38] err [20:46:41] better [20:46:47] yuvipanda|afk: see my netflx link ? [20:46:47] OuKB: make any ense? [20:46:50] *sense? [20:46:52] yuvipanda: --^ [20:46:53] brion: re: scrolling. [20:47:02] tfinc: not yet, will do in a bit [20:47:14] I see where it fails, but whyTF it fails... [20:47:51] brion: can you tell me the state at which it was left? [20:48:04] yuvipanda, uhhhhh afaik it works? :) [20:48:05] well, for context - reference reveal isn't working right now [20:48:16] clicking on references expands ther eferences section [20:48:16] b [20:48:22] but doesn't actually scroll to that [20:48:42] part of the reason seems to be using window.scroll* instead of $("#content").scroll, but even then am running into issues [20:49:10] aren't we working on a nice popup view for those? [20:49:18] we shouldn't have to scroll anywhere imo [20:49:22] brion: yes, but not for next week's release :) [20:49:27] heh [20:49:37] OuKB: is that enough to get you going on a fix? can i revert the debug output in production? [20:49:47] sure [20:51:44] brion: okay, let me dive in some more and poke you if/when I have something specific :) [20:51:51] ok [20:52:03] i think $("#content").scroll should work......... in theory [20:52:37] or [20:52:44] try $("#content .scroller").scroll [20:57:34] ok jdlrobson, im ready when you are [20:57:48] OuKB: fyi i reverted the debug output [20:57:50] k i was trying to get toggling in but i think i should leave it till next deployment [20:57:57] let me just prepare my environment [20:58:33] so jdlrobson: the code review backlog looks… really good [20:58:34] awjr, thanks [20:58:41] https://www.mediawiki.org/w/index.php?path=%2Ftrunk%2Fextensions%2FMobileFrontend&title=Special%3ACode%2FMediaWiki [20:58:50] which means we should be able to deploy from trunk [20:58:57] which makes our lives a lot easier. [20:59:50] jdlrobson: because the production branch currently has a bunch of cherry picked revisions out of trunk, doing a regular merge from trunk -> production will be kind of a pain. so instead, we can just do an svn copy from trunk which should save us a lot of heartache [21:00:01] ok [21:01:06] jdlrboson: so all we really need to do right now is do a some local testing of trunk to make sure it's actually stable and that the changes for today's deployment recorded http://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments#19_March.2C_2012 are all OK [21:01:56] then once it's actually time for deployment, i can go ahead and copy things over to the production branch and get everything deployed to test.wikipedia.org, we'll do one final round of testing [21:02:05] then i'll sync the changes to the entire WMF cluster [21:02:14] then we'll make sure things look ok in the live environment [21:02:22] and hang out for a while to respond to any issues that might pop up [21:02:31] sounds ok to you jdlrobson? [21:02:40] yep but first thing [21:02:45] let me commit the minified javascript [21:02:53] ok cool [21:03:30] now I see why I couldn't repro it... goddamn insane enwiki templates [21:03:35] we will also need to bump the js/css 'version' numbers in ApplicationTemplate.php [21:03:47] OuKB: >_< [21:03:52] is a template breaking the XML? [21:05:52] awjr rhttps://www.mediawiki.org/wiki/Special:Code/MediaWiki/114184 [21:06:06] not sure [21:06:42] but simply importing that article's dump with all its templates didn't produce the same HTML [21:06:57] had to copypaste the div manually [21:07:30] jdlrobson: ok'd [21:07:52] k as far as im concerned we are ready my end to deploy [21:08:35] jdlrobson: ok sounds good. im gonna do some more testing locally and take care of a few other things before 3pm PDT [21:08:52] then i'll start the deployment [21:08:55] k ill do the same [21:12:41] think ive found a bug already [21:13:07] OuKB: did you record your code changes for today's deployment? http://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments#19_March.2C_2012 [21:13:19] jdlrboson: good better now than after deployment :) [21:13:31] more language stuff :S [21:13:42] what are you seeing? [21:14:58] http://mobile-geo.wmflabs.org/he/w/index.php/%D7%A7%D7%98%D7%92%D7%95%D7%A8%D7%99%D7%94:BROKEN?useformat=mobile placeholder - i think ive got the solution [21:15:04] jdlrobson: found one as well - utf8 chacaters are not properly handled in the search box placeholder text [21:15:15] yep exactly the one ive got :) [21:15:17] im on it [21:15:20] word. [21:15:27] awjr, in the light of this problem, I'd rather not deploy my changes today [21:15:31] that is a good one :p [21:17:43] goddamnscrollers [21:19:33] mm [21:19:53] Xml::escapeJsString( doesnt seem to be doing the job here.. [21:20:34] OuKB: ok last time prod was sync'd with trunk was 8 March and then i deployed a fix you had made a few days later (r113488). should i ignore everything else? (https://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&offset=113811&path=%2Ftrunk%2Fextensions%2FMobileFrontend&author=maxsem) [21:21:12] OuKB: which would mean ignoring 113460, 113474, 113759, and 113781 [21:22:00] That MZMcBride character hides well. [21:22:28] Joan: now whenever i see a nick i don't know i just assume it's you [21:22:39] :D [21:22:44] :p [21:24:24] Joan: just curious why don't you use MZMcBride as a nick? [21:24:29] Joan is MZMcBride? [21:24:30] o_O [21:24:30] ok [21:25:29] jdlrobson: http://php.net/manual/en/function.htmlentities.php [21:25:49] jdlrobson: Like htmlspecialchars(), htmlentities() takes an optional third argument encoding which defines encoding used in conversion. If omitted, the default value for this argument is ISO-8859-1 in versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards. Although this argument is technically optional, you are highly encouraged to specify the correct value for your code. [21:26:37] we had a similar problem previously but that seemed to be solved by using Xml::escapeJsString but it doesn't seem to work here - would be good to use the same function across all code no? [21:26:54] jdlrobson: is the placeholder text even going through Xml::escapeJsString? i'm not seeing it [21:27:01] You guys should stop what you're doing right now and listen to some Joy Division. [21:27:03] no previously it was using htmlentities [21:27:25] jdlrobson: so, placeholder is using htmlentities isn't it? [21:28:46] yes preilly [21:28:54] jdlrobson: $placeholder = htmlentities( $this->data['messages']['mobile-frontend-placeholder'], ENT_QUOTES ); [21:29:18] jdlrobson: should be: $placeholder = htmlentities( $this->data['messages']['mobile-frontend-placeholder'], ENT_QUOTES, "UTF-8" ); [21:29:35] i'm seeing a lot of yapping and not a lot of listening to Joy Division here. [21:29:50] or should be changed to Xml::escapeJsString() for consistenc [21:29:51] y [21:30:26] [WikipediaMobile] brion pushed 2 new commits to master: http://git.io/3JBfRw [21:30:26] [WikipediaMobile/master] Bug 35164: high-resolution 'back'/'close' button - Brion Vibber [21:30:26] [WikipediaMobile/master] Merge pull request #178 from brion/close-retina - Brion Vibber [21:30:42] that's what im saying awjr preilly - neither of those are working [21:30:50] Project WikipediaMobile - Nightly builds build #242: SUCCESS in 12 sec: https://integration.mediawiki.org/ci/job/WikipediaMobile%20-%20Nightly%20builds/242/ [21:30:50] brion: Bug 35164: high-resolution 'back'/'close' button [21:30:53] so i'm a little confused [21:30:56] * awjr puts on 'love will tear us apart' [21:31:14] lulz [21:31:16] good plan. [21:31:26] jdlrobson: htmlentities( $this->data['messages']['mobile-frontend-placeholder'], ENT_QUOTES, "UTF-8" ); doesn't work? [21:31:43] nope that's currently live on http://mobile-geo.wmflabs.org/he/w/index.php/%D7%A7%D7%98%D7%92%D7%95%D7%A8%D7%99%D7%94:BROKEN [21:31:43] awjr, yes you should ignore everything else [21:31:59] jdlrobson: you added the "UTF-8" part? [21:32:02] unless some weird caching has happened [21:32:05] yes preilly :) [21:32:20] $clearText = htmlentities( $this->data['messages']['mobile-frontend-clear-search'], ENT_QUOTES, 'UTF-8' ); [21:32:24] $placeholder = htmlentities( $this->data['messages']['mobile-frontend-placeholder'], ENT_QUOTES, 'UTF-8' ); [21:32:46] jdlrobson: I don't see that in trunk? [21:32:52] ah, scroll issues fixed :) [21:32:55]