[01:27:09] how do i make my browser default to spell check my local mediawiki installation's pages in en-au ? [01:29:24] would $wgLanguageCode have any bearing on that? en-au does not seem to be an allowed option for $wgLanguageCode [02:35:47] k-man: does mediawiki even have a spellcheck feature? [02:36:21] ningu: sorry, i meant the in browser spell check feature of FireFox [02:37:44] hmm [02:37:54] yeah, there is en-ca and en-gb but that's it [02:38:14] try gb maybe? [02:40:19] cscott: yo, haha [03:51:53] k-man: regarding en-au: https://phabricator.wikimedia.org/T201985 :( [04:00:07] :( [04:00:21] thanks for carrying the mantle samwilson [04:00:59] I keep meaning to go back and try again, but it feels like it's probably quite complicated! [04:01:20] samwilson: hey, btw any suggestions on this patchset I submitted? should I just ask again if they are willing to merge it? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/618617 [04:02:18] I _think_ the technical issues are all resolved so it's just a question of if people think it's ok to do [04:02:42] and it's core which I've been told is kind of bogged down for approving stuff [04:25:44] hmm, I'm not really sure. I guess if there aren't other examples of languages that aren't both UI and content langs, it's tricky. But it's not something I know much about! [04:38:43] samwilson: ok fair enough :) [04:38:50] I think there are probably some cases [04:40:29] your patch works in my testing, but of course is the same as `ban`, and I don't have a font for ban-bali [04:40:47] samwilson: another thing, cscott seems too busy right now to discuss LanguageConverter work I want to do for Balinese, any idea who else I can talk to? or just submit a patchset blind? :P [04:40:53] samwilson: yes you do! it's in ULS [04:40:55] webfont [04:41:05] oh right! good point [04:41:20] this is Wayan: ᬯᬬᬦ᭄ [04:41:31] it should be in Vimala [04:41:33] (the font) [04:42:21] ningu: sorry, i don't want to be blocking your work. we have been pretty busy with parsoid & LTS work [04:42:32] I figured [04:42:41] ningu: (also i think our timezones don't quite overlap? it's past midnight here on the east coast) [04:42:43] cscott: I already wrote up some code actually [04:43:01] well, I'm on the west coast, I've tried a few times during the day regular hours [04:43:05] (for me) [04:43:27] ningu: ok, i'm just lame then [04:43:35] cscott: my main question is if you think it's reasonable to have a new core parser function like {{#transliterate|ban|ᬯᬬᬦ᭄}} [04:43:41] sorry, change first | to : [04:43:58] the function would take the text and convert it to ban (which is equivalent to ban-latn) [04:44:07] or it could be explicitly ban-latn there [04:44:50] so it's a way to do partial language conversion, w/o turning on language converter for the whole page? [04:44:58] right [04:45:16] we need this for balinese because we want to show the transliterated latin text below the balinese original [04:45:21] that seems reasonable. there's a way to do that in stock language converter, but it's pretty obscure [04:45:26] the function can be deployed in templates and such [04:45:29] oh really?? how? [04:45:53] FYI here is the current patch, I will obviously submit through regular channels: https://pastebin.com/Ct9bS58i [04:46:04] language converter has to be enabled for the page, but presumably your chosen variant would be the 'don't transliterate' variant, then... [04:46:31] see what's nice about this is it's divorced from the user's chosen language or variant [04:46:39] ...then you use https://www.mediawiki.org/wiki/Writing_systems/Syntax#Combined_conversion_flag [04:46:50] huh ok, well I'll take a look [04:47:09] but I can totally imagine a user who wants their interface in indonesian, but prefers a particular balinese script to latin transliteration variant [04:47:34] I'm planning to set the variant-ban user option (which is checked by getPreferredVariant()) from a gadget or similar [04:47:37] that's my understanding at least. but like you say, it's pretty limited because language converter has to be active w/ all the variants you want, it's just going to select a subset of them [04:47:44] so that the particular ban-latn variant will be settable [04:47:49] so it can't be used to transliterate balinese on an english page, say [04:48:10] well the ban variant, not ban-latn variant, but in practice we need it to choose between two or three ban-latn variants [04:49:07] cscott: btw it turned out to be a piece of cake to use ICU rule-based transliterators from within the BanConverter class, I dunno if I did it in the best way in terms of class vars etc, but it works fine [04:49:09] afaik the existing language converter mechanism is pretty limited, most zhwiki users would (i suspect) prefer to be able to specify a preferred variant when zh text is embedded in, say, enwiki [04:49:42] really a user would like to list a set of preferred variants that aren't necessarily strictly related to their preferred language, but we don't have support for that [04:49:44] if they set their user language to zh it should let them choose one, no? [04:49:57] right, but I can add it to our custom interface since we have that interface anyway [04:50:13] a general interface solution would be nice but outside the scope of my work at the moment [04:50:23] but, I was going to just use hte existing user options [04:50:30] (which are api only otherwise) [04:51:20] a #transliterate parser function sounds like a reasonable idea [04:51:32] it's in that diff, line 59 https://pastebin.com/Ct9bS58i [04:52:17] it doesn't specify the variant of the input text so you have to make sure on your own that's sensible, but I realized even if you did tell it explicitly, I don't think it could use the info very intelligently? [04:53:25] it would be nicer to specify the input variant. it is easy to guess for (eg) latin-vs-cyrillic and the like, but very hard to guess right for (eg) traditional-vs-simplified or american-vs-english. [04:53:45] eg what variant is 'lift' [04:54:53] yeah I see, ok [04:54:58] but where would it be passed off to? [04:55:16] there is convertTo but it doesn't take that argument either [04:55:23] nowhere... yet. but parsoid's implementation of language converter would use it. [04:55:28] ok :) [04:56:14] sure, we can build it in [05:02:36] cscott: also, do we need an explicit ban-latn defined with ban falling back to it? I guess we do? [05:02:52] the folks in Bali have been clear on wanting latin to be default [05:03:16] anyway this is already a huge help for me, just to know I can/should move forward on this stuff [05:03:33] hopefully the details can be clarified [05:04:08] I think the code should be ready in ~1 week if all goes well [05:04:43] did you ever send me an email? i thought we'd missed each other on IRC a few weeks back and you had said you were going to email [05:04:50] just wondering if it got lost in my inbox [05:08:17] I did, yes [05:08:20] and asked for an update too [05:08:40] subject line is "LanguageConverter work" and email address is kamholz@panlex.org [05:08:43] what's your email address and/or a subject line? let me dig it out [05:08:52] ah, you beat me. hang on. [05:09:06] at that point I hadn't written any code. now I have so I have a slightly better sense of what's needed/reasonable. but it's basically the same idea [05:10:55] i'd searched for 'ningu' in my inbox after reading the irc backlog, no luck. but now you're in my address book. [05:11:02] haha ok [05:11:16] yeah I chose this nick a long time ago [05:11:21] it means "no one" [05:11:53] i'll send you a reply tomorrow? it's getting late here. but now i know yr email and yr timezone, should help! [05:12:07] no problem, glad we were able to connect [05:12:18] thanks!! [05:12:24] it's pretty late here too [09:59:24] Hello. Firefox happens to cache `mw.Api().get` request, Chrome doesn't. Why so and how do I disable caching? [10:01:35] This is true for different kinds of query requests: API:Options, API:Revisions [10:02:17] I could use post requests, but should I? [10:07:02] (Sorry, not API:Options, but API:Userinfo) [10:08:54] jwbth: add a random parameter on each request, or a timestamp [10:10:46] Vulpix, that should work, but isn't there a native solution? Kind of strange is there is no. [10:14:45] jQuery has a cache: false option IIRC that does exactly that, but I don't know if mw.Api() has that option [10:16:29] > Firefox happens to cache `mw.Api().get()` requests [11:01:24] All GET requests are subject to being cached, unless the server sends the relevant cache directive header to prevent that [21:05:25] hi, just wondering what prospects are for this: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/618617 [21:05:34] Reedy: ^ [21:31:52] ningu: I imagine when the language people are happy it'll get merged [21:41:29] ok cool [21:41:32] who are the language people? :P [21:43:52] The right people look to be listed as reviewers tbh [21:44:00] Raimond added various of the Wikimedia Language team [21:47:35] ok cool [21:47:47] it's more a question about process I guess [21:47:56] should I just wait for them to reply? how long to wait until pinging them again? [21:48:18] I don't want to be too impatient. I also don't want it to get lost :) [21:48:23] We've got patches sitting around for years :P [21:48:27] I know [21:48:42] unfortunately this grant has a timetable [21:48:54] This sort of language stuff probably does better than the average drive by patch [21:49:20] yeah, I'm a bit more concerned about prospects for the LanguageConverter stuff [21:49:29] (which I haven't submitted yet) [21:49:37] Hah [21:49:59] I dont think its ever wrong to be naggy when it comes to mediawiki development [21:50:10] Literally only way to accomplish anything [21:50:14] bawolff: ok :) yeah I know a lot of it is dispersed and volunteer based [21:50:18] which I respect [21:50:24] I just need certain things to be done if possible [21:50:41] the feedback has already improved things i've been trying to do quite a bit [21:50:56] Its not neccesarily the volunteers who are the problem ;) [21:50:56] I mean, do give people some time [21:51:09] * bawolff maybe a little bitter [21:51:12] hehe [21:51:14] Like, if people replied a few hours ago, don't necessarily start pinging them immediately [21:51:21] Reedy: sure, I wasn't going to do that yet [21:51:29] I was just trying to get a better sense on how this works [21:52:06] bawolff isn't completely wrong... Many of us will get patches reviewed by either reviewing other peoples in kind, or knowing the right people to poke [21:52:49] not sure I am able to review other people's? [21:52:52] I dunno how that works either [21:53:08] either way I don't think I know enough to do it [21:53:29] Anyone can create an account and starting reviewing [21:53:34] ah ok [21:53:51] so I don't need permission. I do want to be helpful though and not just adding noise :) [21:57:27] Honestly, reviews from people who are new arent super helpful imo, because usually it takes a while to know what to review [21:57:32] * Platonides gives ningu permission to review [21:57:41] hehe [21:57:43] as far as the review itself makes sense... [21:57:47] ok, well I'll poke around and look at stuff [21:57:59] I mean I've been messing with the mediawiki code for long enough now that I have some clue what's in it [21:58:03] Telling people how/what to review is hard [21:58:04] I mean, a new user could detect an error in a patch by the most veteran comitter [21:58:05] but there are many corners I don't understand [21:58:22] and PHP is not my "first language" :P but it isn't hard [21:58:48] in fact, the hard part is saying "yes, I'm 100% sure everything is ok" [21:58:53] yeah [21:58:55] that's true