[00:00:16] desktop link should point to en.wikipedia.org [00:00:19] i haven't seen that myself, but it's possibly related to the code the MaxSem removed to help with canonical URLs [00:00:32] happens consistently for me on ios [00:00:37] orly [00:00:41] even loads Special:MobileOptions in desktop mode [00:01:14] is this sticky cookies related? [00:01:18] definitely not [00:01:22] well, almost definitely not [00:01:51] what's the difference between $user->isLoggedIn() and $user->isAnon()? [00:02:09] mhm, can't repro in desktop browser [00:02:11] jdlrobson: i cannot reproduce in ios6 [00:02:23] jgonera, one = !another [00:02:27] ok plot thickens jcmish - I can replicate the watch list bug on en.m.wikipedia.org but NOT localhost [00:02:31] suggesting something odd happening on server [00:02:44] \o/! [00:02:46] MaxSem, yeah, but anything apart from that? [00:02:54] no [00:02:57] jdlrobson: weird huh? [00:03:22] jdlrobson, how do I repro https://bugzilla.wikimedia.org/show_bug.cgi?id=43756 ? [00:03:54] jdlrobson: i can't repro bug 43756 in ios6 or on android 4.1 stock browser [00:04:02] MaxSem: I simply loaded up an iOS simulator [00:04:19] clicked settings whilst not logged in [00:04:20] jdlrobson: me too :( but mine is ios6, i gather yours is ios5? [00:04:35] iOS 5.1 [00:06:21] k so I tried it again on staging and on test and I can't recreate it [00:06:35] is it possible that one of the merges happened between the push and might have fixed it? [00:06:38] maybe it was fixed with the recent deploy [00:06:45] yeh i can't replicate it now :( [00:07:24] k I'll close it as fixed and keep an eye on it? [00:07:38] I'm working on an automated to test to catch it going forward [00:07:48] I should be able to to commit it tomorrow by COB [00:10:15] http://wikicity125.oftcc.net/ < tfinc - my friend in London showed me this and the guy who made it - some good ideas there to steal :) [00:11:03] i like the fade out effect [00:11:09] a good way to signal closeness [00:11:21] jdlrobson: good things to steal [00:11:33] visually its very slick [00:14:01] still can't repro https://bugzilla.wikimedia.org/show_bug.cgi?id=43756 [00:29:44] brb changing location [00:35:59] ok, what was the guideline with messages, when do I use text() and when escaped() [00:39:30] text() is unescaped, guess what escaped() is:) [00:40:32] so use the proper function depending on context [00:42:47] no HTML needed => use escaped(), right? [00:44:41] yes [00:46:04] basically, use escaped() or parse() unless you need specifically unescaped text [00:46:57] I updated http://etherpad.wikimedia.org/MFCommitGuidelines with some suggestions [00:47:15] I assume I shouldn't use parse() unless I need mediawiki text [00:48:36] jgonera yeah, there's actually some good documentation around that that is good to take a look at [00:48:42] lemme see if i can dig it up [00:49:08] http://www.mediawiki.org/wiki/Manual:Messages_API ? [00:49:17] yup that's the one [00:49:24] I just wanted to be sure I'm using the right thing, sometimes docs are not up to date [00:49:32] totally [00:49:51] New patchset: JGonera; "(card #308) Add modified date to All view in watchlist [beta]" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43113 [01:09:22] jgonera: in case you haven't seen http://www.mediawiki.org/wiki/Requests_for_comment/API_Future [01:15:16] jdlrobson, those two commits you wanted me to check on Nokia, it's just about making sure that login and watchlist are not visible there on stable, right? [01:15:33] correct (for the time being) [01:15:46] we should probably check that they do render somewhat - in case someone shares a link [01:17:17] well I kind of checked that before I cherry-picked those commits [01:17:30] everything worked pretty well, just no thumbnails [01:18:14] do we use any JS on those S60 phones? even the menu loads as a separate page [01:19:08] thanks for the link to the API future, what should I do to suggest something there, just add a thread in Talk? [01:22:02] New review: JGonera; "Seems to be fine (not displaying watchlist or login on S60 phones)." [mediawiki/extensions/MobileFrontend] (master); V: 0 C: 1; - https://gerrit.wikimedia.org/r/42264 [01:22:04] New review: Jdlrobson; "In addition to this comment I'm not seeing my entire watchlist in a-z mode -it doesn't take into acc..." [mediawiki/extensions/MobileFrontend] (master); V: 0 C: -1; - https://gerrit.wikimedia.org/r/43113 [01:23:12] tfinc, I'm unsure if we need a projector - in principle, that's just 10 people. on the other hand, there might be some group talks [01:23:53] MaxSem: ask for it and be happy you didn't use it [01:25:34] jdlrobson, you there? [01:25:42] yup [01:25:58] what's up jgonera ? [01:26:14] do we use any JS on those S60 phones? even the menu loads as a separate page - is this correct? [01:27:33] New review: JGonera; "Strange, I thought LEFT JOIN would solve that corner case... Anyway, when doesn't an article have an..." [mediawiki/extensions/MobileFrontend] (master); V: 0 C: 0; - https://gerrit.wikimedia.org/r/43113 [01:31:13] hey jgonera sorry my wifi cut out just as you asked if i was there ;-) [01:31:22] do we use any JS on those S60 phones? even the menu loads as a separate page - is this correct? [01:31:34] also see my comment on gerrit: https://gerrit.wikimedia.org/r/43113 [01:34:13] im outta here - talk to you all tomorrow [01:34:37] jgonera: the menu requires jQuery [01:34:50] no need to cherry pick now btw i rebased them both [01:34:52] jdlrobson, ok, then everything is fine [01:34:58] perfect [01:35:00] when? [01:35:06] earlier today [01:35:30] hm, but to apply both of them I need to cherrypick or I can just checkout using gerrit's link? [01:35:33] gerrit-wm: New review: Jdlrobson; "Rebased.. Juliusz is going to test this on a phone which doesn't run jQuery." [mediawiki/extensions/MobileFrontend] (master); V: 0 C: 0; - https://gerrit.wikimedia.org/r/42267 [01:35:38] anyway, I cherrypicked and checked the log [01:35:41] sweet [01:36:02] New review: JGonera; "Except for the whitespace, everything seems fine. No watchlist/login on S60 phones, present on phone..." [mediawiki/extensions/MobileFrontend] (master); V: 0 C: -1; - https://gerrit.wikimedia.org/r/42267 [01:36:20] New review: JGonera; "Ooops, for some reason I finally didn't do LEFT JOIN..." [mediawiki/extensions/MobileFrontend] (master); V: 0 C: 0; - https://gerrit.wikimedia.org/r/43113 [01:36:57] ok, jdlrobson, so what should I show for articles that don't have recent changes? [01:37:08] should I somehow fetch the creation date? [01:41:58] i'm not sure jgonera - i [01:42:03] i guess you could just say [01:42:03] " [01:42:05] "no recent changeS" [01:42:30] jdlrobson, ok, I just found out that I was doing it the stupid way [01:42:40] sweet [01:42:42] and that this info is denormalized in page table [01:42:49] page_touched column [01:43:00] (at least that's what it seems to be) [01:43:19] and this way I could avoid the whole group by thing [01:46:44] jdlrobson, it includes more stuff than recent changes I guess: http://www.mediawiki.org/wiki/Manual:Page_table#page_touched [01:46:55] do you think it's still ok to use that timestamp instead? [01:47:01] eeekkk i spy double encoding [01:47:15] jgonera: not sure i follow [01:47:20] (sorry double encoding unrelated to your stuff) [01:48:13] this page_touched timestamp is updated everytime the page needs to be rerendered [01:48:31] which might happen e.g. on alteration of contained templates [01:48:37] which is not a change to the page itself [01:49:22] I'm wondering if this won't make it show that all the pages were modified not longer than a day ago or something [01:53:50] New patchset: Jdlrobson; "don't show photo uploader on edit page" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43122 [01:53:50] New patchset: Jdlrobson; "Make test for infobox and navbox's stricter" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43123 [01:54:01] jgonera: i'm not sure [01:54:17] just don't show the last modified date if it's not there? [01:55:38] hm [01:55:54] I'll hold on with this and ask someone who knows the DB schema well tomorrow [05:12:18] New patchset: Jdlrobson; "fix broken history link in beta" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43140 [05:12:44] New patchset: Jdlrobson; "allow ability to unwatch articles in watchlist view" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43141 [05:40:49] New review: Spage; "Some suggestions to make it more resilient. I got it to log a _valid: true event on my local instan..." [mediawiki/extensions/MobileFrontend] (master); V: 1 C: -1; - https://gerrit.wikimedia.org/r/43099 [15:40:47] Change merged: Jdlrobson; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/42905 [15:45:27] New patchset: Jdlrobson; "locally track languages the reader can speak" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43002 [15:45:28] New patchset: Jdlrobson; "prompt people to begin translations of articles" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43003 [15:45:28] New patchset: Jdlrobson; "on new pages add a textarea" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43000 [15:45:28] New patchset: Jdlrobson; "Allow easy method to translate lead of an article" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43001 [15:45:29] New patchset: Jdlrobson; "Create generic loader in mw.mobileFrontend" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/42998 [15:45:29] New patchset: Jdlrobson; "use M.showLoader when saving an article" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/42999 [15:45:29] New patchset: Jdlrobson; "only close notifications with class locked via button" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/42997 [15:46:58] jdlrobson, travelled again? [15:47:06] New review: Jdlrobson; "Don't encourage use of globals use mw.config.get (update jshintrc)" [mediawiki/extensions/MobileFrontend] (master); V: 0 C: -1; - https://gerrit.wikimedia.org/r/43098 [15:47:16] always traveling Max ;-) [15:47:31] about to go out for an early morning walk [15:49:41] mmm, I've delted almost 3M killlist entries on enwiki already and it doesn't want to ever stop [15:57:27] haha the wikipedian never sleeps [15:57:43] right back in 2 hours. need to find some totem poles.. [17:09:30] Change merged: awjrichards; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/42949 [17:37:35] totem pole success! [17:37:41] ?! [17:37:42] jdlrobson: saw that :P [17:37:52] just went for an early morning stroll [17:37:53] * awjr checks facebook [17:37:54] ahhh [17:37:58] jdlrobson: did you know they existed before, or ...? [17:38:08] yup [17:38:10] that's a cool one [17:38:11] as always ;-) [17:38:20] mmm it didn't share the other 3.. faol [17:39:39] now i just need some breakfast [17:40:29] mm maple walnut muffin [17:41:09] jdlrobson: you + timezone math confuse me [17:41:26] i'm on PST [17:41:28] but jetlagged [17:41:33] so it works in my favour [17:41:37] up at 6am :D [17:42:15] jdlrobson: heh [17:42:28] jdlrobson: so tfinc told me I'm technically still not staff until Monday [17:42:28] HR [17:42:50] boooo [17:42:52] get out of irc! [17:42:54] ;p [17:43:02] :( [17:43:39] oh and YuviPanda with regards to blog post - best blog posts allows the user to jump to their own conclusions that something is shit without you spelling it out :) [17:45:48] jdlrobson: hmm, perhaps I can point to the Daring Fireball's explanation (which seems to be generally 'accepted') as that restriction being there for security reasons as bullshit. [17:57:50] Change merged: awjrichards; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/40306 [17:58:14] i need someone else to merged this - MaxSem? https://gerrit.wikimedia.org/r/#/c/43030/ [17:59:09] awjr, sorry - just noticed a minor problem:P [17:59:16] ! [17:59:20] this is why we code review :) [17:59:41] well, I noticed in in code I've already +2'd;0 [17:59:48] :O [17:59:53] doesn't break anything though [18:00:04] morning all [18:00:09] yo [18:00:18] * YuviPanda waves at brion [18:00:21] awjr, so we're not deploying today? [18:00:29] * brion waves YuviPanda right back [18:00:31] MaxSem, no, we are [18:00:59] mornin brion [18:01:15] brion are you going to be around when i push out zero changes this afternoon? (3-5pm PST) [18:01:22] yes i'm in the office all day today [18:01:26] huzzah [18:01:32] so i filed a bug on Firefox OS that the wifi hotspot feature breaks if you put a space in the password [18:01:44] somebody posted a patch that puts the password in quotes on the command line [18:01:50] i asked "what if the password has a quote in it?" [18:01:54] they opened a new bug :P :) [18:01:57] ! [18:02:06] better patch on it though :D [18:02:50] it's a weird OS… javascript producing commands for low-level parts of the OS to run! [18:02:55] brion, they should uuencode it [18:03:05] heh [18:04:38] brion: clearly, ban quotes and spaces in WiFi passwords [18:05:12] hi everyone, can someone send me their LocalSettings? I need to set up the env again on my home laptop [18:06:29] mine's almost as perverted as WMF config [18:06:31] they call them laptops because you can transport them ;) [18:06:40] only a couple orders of magnitude away [18:07:47] brion, well, I haven't predicted that I'd get worse and I usually don't need two laptops at home ;) [18:08:07] jgonera: https://gist.github.com/4504356 <- here's a few core bits you don't want to forget [18:08:14] any will do, I'll just pick what I need from it [18:08:16] thanks [18:09:40] New patchset: Jdlrobson; "log watchlist actions (beta)" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43099 [18:09:40] New patchset: Jdlrobson; "bring global variables to javascript" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43098 [18:10:10] jgonera: https://gist.github.com/8747eb403eb7e81f1f3a [18:10:25] note that my setup is more robust than your avg localhost [18:11:27] i have a separate domain configured for .m, i have ssl set up, multiple wikis using Single User Login (with CentralAuth), memcache and varnish also configured [18:11:35] awjr, thanks, maybe I'll learn some new stuff too [18:12:03] awjr, are you using vagrant? [18:12:08] jgonera no [18:12:15] on my todo list is to vagrant-ify my setup :) [18:12:46] it would be nice to have a full package that would allow you to easily test MF with stuff like ssl, separate .m domain, etc [18:13:09] isn't that what Ori has been working on? [18:13:35] jgonera: ori set up a basic vagrant instance with a simple MW install - i dont know if he's working on anything more robust [18:16:56] MaxSem: $mobileContext->shouldDisplayMobileView() === false is correct in https://gerrit.wikimedia.org/r/#/c/43030/1/includes/MobileFrontend.body.php [18:17:10] it returns either true or false [18:17:25] i am failing to see the problem [18:17:40] remove "=== false" [18:17:57] but then it would not do what i want it to do [18:18:12] which is to early return if we are not supposed to be displaying the mobile view [18:19:19] meh !$mobileContext->shouldDisplayMobileView() [18:19:59] but… that is, in essence, exactly the same as what is there now [18:20:24] do you have something against === false? [18:20:59] if ( $foo === false ) is equivalent to if ( !$foo ) [18:21:08] just much more misleading [18:21:45] I think it's a matter of preference. is it mentioned somewhere in mw coding style? [18:21:51] how is that misleading? the method always returns an actual boolean value [18:22:20] why are you comparing bools at all? [18:22:36] because i want to take a particular action of that method returns… false [18:22:43] s/of/if [18:22:53] !$foo does exactly the same [18:23:12] personally, i find !$mobileContext->shouldDisplayMovileView() easy to mistake with $mobileContext->shouldDisplaymobileView() [18:23:15] it's easy to miss the '!' [18:23:25] so i prefer to be explicit [18:23:34] you're the first person I know who has this preference [18:23:39] :D [18:24:10] MobileFrontend is forcing my desktop logins to https [18:24:18] this is bad as i have no https on my local server [18:24:34] brion, we're discussing a fix of it right now^^^ [18:24:39] yay [18:24:44] brion once the patchset max and i are arguing over is merged, that should not be a problem [18:24:49] excellent [18:25:12] brion, but that isn't going to happen within next few months [18:25:17] bikeshedding! [18:25:26] brion: in the mean time: $wgMFForceSecureLogin = false; [18:25:28] in localsettings [18:25:36] blug [18:25:43] yeah, MaxSem and i need to fight to the death first over something barely consequential [18:26:22] jgonera MaxSem, there's nothing on the topic in the MW PHP coding conventions [18:26:44] awjr, I've just checked too [18:26:52] i don't REALLY care that much, so i"ll just use ! [18:27:05] then I guess it doesn't matter and if you want to enforce it MaxSem then add it to http://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP ;) [18:27:16] lol [18:27:36] I'll just use precedent law [18:27:50] fuck my tool server account expired [18:27:50] * MaxSem looks happily at our codebase [18:27:57] brion: welcome to the club :P [18:28:30] aaaaand i can't log in with my tool server password [18:28:32] well fuck that. [18:28:43] brion: IIRC you'll need to file a request in... JIRA! [18:28:51] nah i'll let it die [18:29:00] i can use another copy of SVGEdit :) [18:30:01] i wish there was an easier way to escape the watchlist then having to hit back a bagillion times [18:30:20] awjr, agreed, we need to add the hamburger asap [18:30:25] awjr: we need the hamburger asap [18:30:26] Maryana said the same thing [18:30:29] hah [18:30:31] aaaand now im hungry [18:30:32] ;) [18:30:42] the hamburger must persist! [18:30:48] Maryana awjr: it's also vital [18:31:05] exhibit a: http://en.m.wikipedia.org/wiki/Special:Watchlist [18:31:15] how do you get home now hey? hey?1 [18:31:16] muhahaha [18:31:24] ahhhh trapped in the mobile view [18:32:08] New patchset: awjrichards; "Ensure https enforcement for login/acct creation only happens on mobile" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43030 [18:32:13] MaxSem ^ [18:32:21] awjr, even funnier: I once managed to be stuck in desktop mode on mobile domain [18:32:28] :O [18:33:21] it vanished itself after a week. guess something with cookies [18:33:39] too much testing [18:33:46] that is totally whacky [18:33:48] Change merged: MaxSem; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43030 [18:35:35] New patchset: Jdlrobson; "assume the watchlist has taken pageimages api into account" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/43237 [18:36:55] yay thanks MaxSem [18:45:11] working on consolidating our mobile icon set onto a single canvas so we can use sprites. any objection? jdlrobson awjr and anyone else that's interested [18:46:11] my only worry with sprites is is they have wikipedia specific branded icons in them - it should be trivial for a different project to change a single image rather than having to change a single sprite canvas [18:46:21] hey awjr [18:46:22] hate spriteesssss [18:46:38] i think brion hates sprites though [18:46:44] oh there we go [18:46:47] i can't remember why :) [18:46:50] the only good reason to use sprites is to reduce http hits. we already do that by embedding data urls [18:47:19] this is true [18:47:33] part of the reason i wanted to do it was to ensure that we were using a consistent icon set [18:47:37] hi jcmish [18:47:42] you guys can beat me up later [18:47:48] it's also a nightmare to maintain them [18:47:52] munaf, is using sprites possible if we scale icons? [18:48:00] we end up with "icon1", "icon2", "icon3" and random numbers as offsets. eww [18:48:13] brion: what if you maintain them in less? [18:48:33] munaf: to what benefit though? [18:48:46] (I mean background-size property) [18:49:15] brion, the added benefit is just one http request to fetch all of them, but I don't know if we use that many for this to matter [18:49:29] it's tricky jgonera, basically i think the only maintainable way to do it is with less or sass so you can have naming, have background position offset variables instead of random numbers [18:49:30] etc [18:49:36] right, we avoid that by running the CSS through ResourceLoader with the magic @embed directive [18:49:55] they get embedded as data uris and no http hit need be made [18:50:01] howdy awjr [18:50:10] quick question [18:50:11] hi jcmish [18:50:13] sure [18:50:18] anyway, i hate sprites. but if you guys gotta use em, just make them maintainable :D [18:50:26] munaf, I agree, but e.g. if the icon is 64x64px but we want to display it as a smaller one with background-size, won't it show the whole icon set then? [18:50:28] so I went through all the bugs for mobile web and I'm looking at them to see priority to discuss in our meeting [18:50:46] does every dumbphone support sprites? [18:50:46] jgonera i think we'll need seperate classes for each standard size [18:50:53] brion, I didn't know it worked this way, interesting [18:50:55] and I'm now working through the app bugs but more for basic triaging [18:51:03] yeah it's a nice fun feature [18:51:06] I don't need to really include those for our planning right? [18:51:19] the images get expanded slightly from base64 encoding but gzip zips them back down [18:51:21] munaf, that might be a problem, I guess in a few places we use em units to scale the background [18:51:36] (I'd need to double check though) [18:51:58] awjr: ha we wouldn't beat you up :D [18:52:01] hmm, yeah that is likely an issue jgonera. c [18:52:09] rap. [18:52:44] ok, i'm going to hold off on this for that reason. hopefully having a dropbox folder called "icons" to which everyone has access will ensure consistency well enough [18:52:46] jcmish: re app bugs, you are correct - we dont need to cover those today [18:52:57] kayo sounds good [18:53:24] munaf, sure, as long as its just one folder for all of them [18:53:32] yup :) [18:53:35] that's the plan jgonera [18:53:43] we could probably even write a script which would update all icons from dropbox [18:54:18] actually the background size is a good point with sprites when you consider responsive design [18:54:30] ah, well if there's a naming convention you want me to stick to let me know [18:54:35] i think the icon set is currently maintainable via use of a folder... [18:54:35] jgonera ^ [18:54:51] smaller screen sizes will use smaller fonts and smaller icons [18:55:25] munaf, not sure as of now what the best naming convention would be [18:55:47] for now it'll be icon-*-NxN.png :-) [18:56:14] jdlrobson, but if there was a script which we run periodically, the designers wouldn't have to poke us everytime they update an icon [18:56:19] argh [18:56:23] brb [18:56:46] jgonera if you have the dropbox folder sync'd on your machine you can set it up to give you a growl when it's updated [18:59:57] just hardlink it the way that dropbox and git would compete for updating the file. fropbox will eventually win. then just commit it [19:13:20] Hi, I'm trying to get Kannada webfont support added to wikimedia-mobile app. I see that Tamil is already working . [19:13:32] Is there any pointer to make it work for kn_INT [19:13:36] *kn_IN [19:13:48] hi techfiz [19:13:56] for the app or for the mobile site? [19:13:58] hi brion [19:14:06] For Android App [19:14:20] * brion vaguely remembers an email about this he hasn't responded to yet :D [19:17:06] * brion hmms [19:17:25] techfiz: i'm testing kannada on my android 4.1 phone, it appears to work (though i'm not sure it's rendered all correctly) [19:17:45] brion: right, it works just fine on 4.1 and 4.2 (Nexus 7) [19:17:54] brion: is it a bug that we link to commons.wikimedia.org - https://bugzilla.wikimedia.org/show_bug.cgi?id=43627 [19:18:04] i'm tempted to close that bug and just fix the redirector.. as it doesn't seem like a bug [19:18:07] yeah http://www.android.com/about/jelly-bean/ lists it among new languages supported [19:18:35] jdlrobson: i'd agree on that [19:19:44] right, but its working for Tamil on 4.0.4 on Micromax A100. So I thought it should work for Kannada , Telugu and Malayalam also. [19:20:19] if we pull the fonts in, it may or may not work yeah [19:20:20] Also, there is an another issue with webfont support for mobile site as well. I don't think its working for Kannada [19:20:38] if only upgrades were more consistent on android devices i'd just say "upgrade!" but most people can't [19:21:10] :) [19:21:58] techfiz: any patches ready to go or shall i make a note in bugzilla and assign it to me to test later? :) [19:22:17] When I open desktop site on my chrome browser, only part of the content is appearing fine with the support of webfont. The main body doesn't appear. [19:23:12] brion: nope I don't have any patches ready. I need some hand holding to play around with this.. I haven't tried android dev hands on :P [19:23:35] ok i'll put a bug report together for now [19:23:40] New review: Jdlrobson; "Make it 404." [mediawiki/extensions/MobileFrontend] (master); V: 0 C: -1; - https://gerrit.wikimedia.org/r/42196 [19:23:43] Cool thank you [19:23:51] techfiz: usually, for language support, there's precious little that app devs can do :( [19:23:57] it's mostly in the hands of the manufacturers [19:24:13] Change merged: Jdlrobson; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/42131 [19:24:15] YuviPanda: hey... nice to catch up with you here.. [19:24:21] :) [19:24:58] techfiz: feel free to add notes here https://bugzilla.wikimedia.org/show_bug.cgi?id=43835 [19:25:15] Agree.. I thought I shall take help of some of you here to make it work for kn_IN ;) if at all its easy hack [19:25:18] YuviPanda: yeah… *if* the renderer works ok we can embed fonts, if it doesn't work then we're stuck [19:25:28] brion: sure. will do [19:25:42] brion: yeah, IIRC 4.0 had a sortof-working Tamil renderer but *only* inside webkit [19:25:48] ugh [19:26:08] brion: rendering seem to be working. I see the header and left menu appearing fine on chrome (Desktop version of Kn:Wiki) [19:26:23] ok that's good probably :) [19:26:31] my 4.0 test device is at home so i'll pull up an emulator [19:29:46] looks like it works in browser [19:29:52] we'll try it and see if it works in app :) [19:30:35] Nice :) yes.. mobile version works on browser though [19:39:53] ok lemme try this [19:41:19] brion: techfiz is also interested in the Android IME stuff, so I now have a free tester :) [19:41:27] awesome [19:42:37] YuviPanda: I wrote test cases for kn-itrans during dev camp :) 600+ tests [19:42:48] techfiz: /\ [19:42:52] thalaiva! :D [19:43:17] I mean kn transliteration [19:43:35] I know, but I don't know how to say that in Kannada [19:43:35] only Tamil [19:43:35] lol [19:44:11] nm ;) its Devru in Kannada :P which I'm not [19:44:44] Devaru / Devru = God in Kannada hope its the same meaning for thalaiva! [19:47:53] :D [19:50:50] aha [19:51:01] it won't take the .woff but it'll take the .ttf [19:56:06] any tfincs around? [20:00:28] techfiz: can you try the .apk i attached on https://bugzilla.wikimedia.org/show_bug.cgi?id=43835 and just confirm that the body text renders correctly when set to Kannada? [20:00:37] the headings will display as boxes for now [20:00:50] brion: sure.. just a moment [20:08:40] brion: yay! it works [20:08:45] awesome :D [20:08:57] ok that's good news, i'll generalize it a bit later [20:09:59] Sure thing..I just went through your patch... :P good one . Thanks brion [20:10:17] lol [20:10:22]