[14:33:23] so I went to the zoo yesterday with my family. my five year old decided that it'd be cool to divert the flow of the stream in the kids area. [14:33:47] its was glorious to see a croud of ~6 five year old work together to build a dam [14:34:18] then a ~7 year old came over and took it all apart in seconds.... [16:58:38] instant life lesson [16:59:42] Language Engineering office hour starts here soon (less than a minute) [17:00:12] #startmeeting Language Engineering monthly office hour - November 2014 [17:00:12] Meeting started Wed Nov 12 17:00:12 2014 UTC and is due to finish in 60 minutes. The chair is arrbee. Information about MeetBot at http://wiki.debian.org/MeetBot. [17:00:12] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [17:00:12] The meeting name has been set to 'language_engineering_monthly_office_hour___november_2014' [17:00:59] Hello everyone, Welcome to the monthly office hour of the Language Engineering team of the Wikimedia Foundation [17:01:05] o/ Hi arrbee! [17:01:13] And everyone else. [17:01:17] * Romaine greets everyone [17:01:23] I am Runa, the Outreach co-ordinator for our team [17:01:34] Hello Niharika!! Nice to see you [17:01:43] :) [17:01:44] Hello Romaine [17:02:00] Before everything else, we start with the standard message [17:02:18] IMPORTANT: The chat today will be logged and publicly posted. (See big bold note on the channel topic area) [17:02:48] Our last office hour was held on October 15th, 2014 [17:02:58] logs at: [17:03:01] #link https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2014-10-15 [17:03:22] A quick introduction :) [17:03:52] Our team builds and maintains language features and tools for the wikis in more than 300 languages [17:05:06] Present along with me today are aharoni kart_ jsahleen and Nikerabbit [17:05:40] We are a truly global team and work from several places in different countries around the world [17:05:59] (sometime from island too :)) [17:06:29] Our team page on mediawiki.org has details about our projects and how you can participate in them [17:06:35] #link https://www.mediawiki.org/wiki/Wikimedia_Language_engineering [17:06:49] kart_: :P [17:07:02] morning ;) [17:07:23] Hello [17:07:24] Olá! [17:07:31] :) [17:07:39] In our last office hour, we had mentioned about the second version of Content Translation that we completed on September 30 [17:07:45] Namaste. [17:08:09] However, we had to delay the deployment and availability until some technical issues could be fixed in the beta servers [17:08:29] That was sorted earlier this month [17:09:17] and we now have Catalan, Spanish and Portuguese translation support on the shiny new version [17:09:27] supported through Apertium [17:10:04] you can try playing with the tool at: [17:10:08] #link http://en.wikipedia.beta.wmflabs.org/wiki/Special:ContentTranslation [17:10:47] The page looks a bit empty currently due to a bug that we recently caught (related to Parsoid) [17:11:39] We have more details about this update in one of our recent blog posts: [17:11:41] #link http://blog.wikimedia.org/2014/11/03/announcing-the-second-version-of-the-content-translation-tool/ [17:12:49] If you are interested to know about the technical issues that delayed us, there is another post that will published later today or tomorrow on the Wikimedia blog [17:13:05] Do please check back there for the details [17:13:39] For the next round we are looking at some other language pairs which are supported on Apertium [17:14:07] And may have a reasonable number of bilingual users who can make use of the tool [17:14:49] We are planning to do a survey sometime this month to better understand which language pairs can be prioritised [17:15:08] So do please let us know of any suitable candidate language pairs [17:15:39] Romaine has already suggested Dutch to Afrikaans, so thats one of the language pairs in evaluation right now [17:16:07] Dutch <-> German I would like even better [17:16:42] Romaine: okay [17:17:06] What we will do next is to check how well Apertium supports these language pairs [17:17:15] Is Chinese <-> English possible on Apertium? [17:17:26] in this case Dutch to German and the other way round [17:17:26] both languages are very similar but many users do not speak the other language [17:17:39] kclau: most probably not. Let me check though [17:17:53] kclau: Unfortunately, no. [17:18:28] #link http://wiki.apertium.org/wiki/List_of_language_pairs [17:19:13] Romaine: Dutch <-> German is in the incubator stage right now [17:19:44] We are concentrating on the released pairs for now [17:20:01] Mainly for reliability [17:21:06] But do lookout for the survey sometime in the next few weeks [17:21:08] Yes, I saw Dutch <-> German in the list [17:21:27] too bad. Will other translation machines be supported in the future? translate.google.com can do online translation for Chinese <-> English. [17:22:06] kclau: we are looking into other machine translation engines, but there are technical and legal issues to work out. [17:22:45] and reliability [17:23:58] Yes [17:23:59] Yes - they are not Free Software, so we need approval from the legal department and from the community. [17:25:12] Technically it's not too complicated, but there are issues such as - how to comply with the terms of use of these engines, how to credit them, how to ensure our editors' privacy, whether we want to use non-free software at all, etc. [17:26:12] Our major concern while looking at new language pairs is that the translation engine has to really give us meaningful workable output of high quality [17:27:16] So far we have seen wonderful response for the Spanish-Catalan pair [17:27:38] We are now looking to see how the other pairs are working [17:28:17] * arrbee wonders if there are any Portuguese translators/editors around here today [17:28:43] Hi all, how good is the accuracy of the translation? [17:29:01] Oscar_: did you have any particular language pair in mind? [17:29:21] Oscar_: the accuracy of machine translation must be judged by the Wikipedia editors who know that language. [17:29:40] We enable a machine translation engine if people who know that language tell us that they think that it's good enough. [17:29:48] Spanish, I'm from Venezuela (greetings all :)) [17:29:53] is there a way to stimulate a certain language pair, to get out of nursery and becoming a trunk one? [17:30:00] Oscar_: Welcome :) [17:30:16] And even after that we very strongly encourage to check all the translations that are produced by the machine translation engine, [17:30:19] Oscar_: The Catalan editors were very happy with the translation quality they got from Spanish [17:30:33] and we discourage people from publishing 100% machine translation. [17:30:49] Oscar_: They found the MT and editor working well for their editing workflow [17:31:03] So even if the translation from Spanish to Catalan makes the Catalan speakers happy, as arrbee says, we still strongly suggest to double-check every paragraph. [17:31:39] Oscar_: Someone even mentioned that they observed they could cut down approximately 30% of the time they earlier needed [17:32:39] Oscar_: But we are waiting for feedback from users on how well the Spanish<->Portuguese and Catalan <-> Portuguese translation works [17:33:12] Oscar_: so you are most welcome to try out if you do speak any of the other 2 languages :) [17:33:59] Romaine: Apertium surely has a process for that [17:34:04] kart_: would you know? [17:35:04] Romaine: Yes, you need to contact Apertium developers. [17:35:39] They need people who know the two languages well to go over the dictionaries and the lists of grammar rule transformations and to test the quality of the translations. [17:36:05] There's also an #apertium channel. [17:36:11] Tell them that we sent you :) [17:36:17] lol [17:36:19] +1 aharoni. Most important part is Grammar rule, avaibility of dictionaries and testing. [17:37:27] Thanks aharoni kart_ [17:37:50] It would be a big help if more language pairs are stabilized on Apertium [17:38:31] Meanwhile, there are also some updates from the new features front [17:39:31] We plan to provide a dashboard for translators to see all their translations and status [17:40:06] Also a way to save the translations as draft and resume later [17:41:07] Since Content translation (by definition) is a cross wiki process, the dashboard will be common for all wikis [17:41:40] i.e. users can access the same dashboard from any wiki [17:42:05] We have a few illustrations for the dashboard [17:42:26] 1. Regular state: http://i.imgur.com/v3Qd9Nn.png [17:42:50] 2. Initial state: http://i.imgur.com/8jlJhbd.png [17:43:29] The dashboard will also provide suggestions for starting new translations [17:44:04] The third illustration is for what happens after the user clicks on a suggestion [17:44:11] 3. http://i.imgur.com/X157ygI.png [17:44:34] This is still under development [17:45:31] Going forward, we may also allow translators to resume draft translations made by another translator [17:46:01] jsahleen: aharoni: Do you have anything to add to this? [17:46:58] another feature that we hope the editors' communities will like is this: [17:49:31] if we suspect that an article has a lot of machine-translated text, but the translator insists on publishing it, then a category will be added to it, [17:50:12] so that the community will be able to check it and improve it or delete it if necessary. [17:51:40] oh and btw, we also added categories in the new version [17:52:18] That had been one of the requested features [17:52:49] yes - categories are adapted automatically. [17:52:56] this is one of my favorite features ;) [17:53:04] developed mostly by Joel [ jsahleen ] [17:53:17] Yes, categories are now automatically adapted and you can manage them (add delete) from the interface. [17:53:24] My pleasure. ;) [17:53:56] we just noticed that that's one of the first things that translators do when they translate an article, so we are trying to do this automatically and save the translators a few minutes. [17:54:46] aharoni: that can be difficult as often categories do not match between Wikipedias [17:55:14] We do this if there is a directly corresponding category according to the interlanguage links. [17:55:34] I often have to pick a category higher in the category tree when translating [17:55:53] Yes, I know that this happens often, [17:56:03] and it's possible that we'll implement something like that in the future, [17:56:07] Romaine: We adapt categories in much the same way we adapt links. Only those categories for which there is an equivalent category in the target are carried over. [17:56:12] but for now we only do directly corresponding categories. [17:56:40] * Oscar_ still frightening to translate something to catalan :-) [17:57:02] are links only adapted and inserted if the article is available in the language it is translated to? [17:57:16] Oscar_: what about Portuguese? :) [17:57:51] Oscar_: oh btw.. you can even translation from Catalan to Spanish. We enabled that direction of translation too. [17:57:54] Romaine: Yes [17:58:01] ok [17:58:24] That would be more easy arrbee [17:58:33] * arrbee notices we have 2 more minutes left to end the hour [17:58:37] Oscar_: :) [17:59:21] Are there gonna be any OPW interns working with them team in the upcoming round? [17:59:26] the* [18:00:05] Niharika: not announced yet :) [18:00:14] Niharika: We hope so, but do wait for the announcements from Quim [18:00:28] Ah, okay. :) [18:00:29] okay ... we are out of time today [18:00:43] * arrbee thinks today the hour ended faster [18:00:56] Thanks everyone for coming. [18:00:56] Thanks, everyone. [18:01:12] If nothing changes, our next office hour will be on December 10, 2014, but do lookout for the announcements for the exact date [18:01:26] Our mailing list is mediawiki-i18n@lists.wikimedia.org and IRC channel is #mediawiki-i18n [18:01:44] I will post the logs the metawiki in some time [18:01:47] Thanks again [18:01:47] thanks all for the work! [18:01:55] #endmeeting [18:01:55] Meeting ended Wed Nov 12 18:01:55 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [18:01:55] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-17.00.html [18:01:55] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-17.00.txt [18:01:55] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-17.00.wiki [18:01:56] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-17.00.log.html [18:02:19] Romaine: our pleasure. Its a project close to our hearts :) [18:02:48] :) [18:06:35] guillom: Is there an office hour? :D [18:06:44] Oh, different channel. Silly Mark. [18:06:50] marktraceur: wrong channel :) [18:06:54] marktraceur: it's not a real office hour, it's a support session ; but yes :) [18:06:59] Ah, never mind then [22:02:55] mmm, no RFC review today? [22:03:20] * StupidPanda points MaxSem to enwiki [22:03:24] EVERY DAY IS RFC REVIEW DAY! [22:04:05] Yes, there is an RfC review today [22:04:14] #startmeeting RFC meeting [22:04:14] Meeting started Wed Nov 12 22:04:14 2014 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:04:14] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:04:14] The meeting name has been set to 'rfc_meeting' [22:04:49] #topic RFC meeting | PLEASE SCHEDULE YOUR OFFICE HOURS: https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [22:05:48] #topic Better PHP profiling | RFC meeting | PLEASE SCHEDULE YOUR OFFICE HOURS: https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [22:05:55] #link https://www.mediawiki.org/wiki/Requests_for_comment/Better_PHP_profiling [22:05:59] ok... [22:07:13] so I scheduled this old RFC so that bd808 and any other involved people could talk about the possibility of removing the existing profiler [22:07:25] maybe from all of MediaWiki, or maybe just from substantial parts of it [22:08:08] in principle, this sounds like a good idea [22:09:03] We made some updates to the RFC a few hours ago [22:09:34] a far better visualisation would be needed though because profiling information will be available for every function, thus creating a lot of white noise [22:10:10] MaxSem: Yeah. The initial patch that was just merged has some support for filtering [22:10:37] so the things we like about the current profiler that wouldn't be in xhprof are: [22:10:49] there is a reasonable visualization of the call tree in the xhprof library, but it could certainly be better [22:10:56] * ability to do custom profiling names, like abstracted SQL text and template names [22:11:03] sub-function profiling [22:11:17] * ability to split up expensive functions in order to identify more specific optimisation targets [22:11:34] MaxSem: just split the functions. big functions are bad anyway. if it's more than one screen, it's too big. [22:11:49] well, it's not necessarily possible [22:12:06] * bd808 wishes Aaron were here [22:12:08] I mean, when you're optimising, you often want to know the cost of each line of code [22:12:43] so splitting every line of code into its own function... [22:12:52] ^d and I were talking about sub-section profiling this morning. [22:12:56] well, I suppose that's Jeroen's usual coding style, but maybe it's not for everyone ;) [22:13:02] heh [22:13:35] in terms of cost per line, i'm not sure thats all that valuable in production profiling. It is certainly something you will want in dev environment though [22:13:42] i have actually moved quite far his way with respect to function size. small functions are good. but i see your point [22:13:45] in that respect, function sized profiling of 20-50 lines should be plenty [22:13:56] Our thought for now is that we would like to find a way to support that via the tradition means while deprecating/removing function level profling calls with wfProfileIn()/wfProfileOut() [22:14:17] office hours... [22:14:49] bd808: sounds good - but there should be a way to combine the output of the two methods into a unified view. well, ideally there would be [22:15:05] That would be nice [22:15:15] maybe we should think about removing but not deprecating? [22:15:25] We could always ask for / implement additions to xhprof too [22:15:43] yes, that is worth considering [22:15:46] do we have any insight into how facebook uses their xhprof profiles? [22:16:00] TimStarling: Yeah. That's a better way to put it I think. We can kill off the useless calls. [22:16:00] since they wrote it and all [22:16:33] can xhprof be enabled/disabled from inside php? can we easily do sampling? or is that not necessary? [22:16:45] DanielK_WMDE_: yes its enabled/disabled from inside php [22:17:00] And interestingly with xhprof we can find out what those calls really cost. If they are cheap enough we can just leave them be. [22:17:02] you call a start funtion with flags for what kind of profiling, and then get n arry of profiling data back when you call the end function [22:17:11] DanielK_WMDE_: that's the only way to enable it actually [22:17:18] ic [22:17:26] DanielK_WMDE_: Take a look at https://gerrit.wikimedia.org/r/#/c/168930/12 [22:17:54] it needs to be explicitly activated at the start of each request, and then explicitly shut down, and then you need to put the data somewhere [22:18:06] so not like xdebug at all [22:18:15] so ?forceprofile=1 will still work... [22:18:23] MaxSem: yes [22:18:24] nice [22:18:34] forcetrace is trickier [22:18:56] ProfilerSimpleTrace is not like the other profilers [22:19:15] and xhprof doesn't really have an equivalent [22:19:17] having a simple way to get profilign info inlined in the html output would be *extremely* useful. [22:19:28] especially if it was in a format i could load into cachegrind or something [22:19:35] They have a stack sampling mode but it's not the same thing really as our trace [22:19:40] DanielK_WMDE_: already can be done, but not for cachegrind [22:19:40] we also have $wgDebugFunctionEntry [22:19:44] unfortuantly cachegrind compatability is independant from xhprof [22:19:49] with forceprofile=1 [22:19:52] but hhvm team is working on something that integrates with cachegrind [22:20:49] I have grand ideas about visualization tools but they are really something that I'd rather find out in the world than have us build [22:20:58] I don't think $wgDebugFunctionEntry/forcetrace is really essential [22:21:32] Aaron said he really likes it in some circumstances (frocetrace) [22:21:38] *forcetrace [22:22:00] But if we can generally live without it that's obviously easier [22:22:54] say if we remove most wfProfileIn/wfProfileOut calls but retain some important ones, like custom names [22:23:08] would it be possible to merge the data in the output generator? [22:23:31] Yeah. I think we could make a hybrid profiler that did that [22:23:49] I think that is one solution, the other is to patch xhprof [22:23:50] Or at least a combined report that gave both sets of data [22:24:34] It would be interesting to see what hhvm and xhprof think of extending the api [22:24:45] which is another gotcha. 2 upstreams now [22:25:24] https://github.com/phacility/phabricator and https://github.com/facebook/hhvm/ [22:25:37] wasn't the Zend xhprof also written by facebook? [22:25:47] sorry https://github.com/phacility/xhprof [22:25:53] yes, and the lead maintainer still works for facebook [22:26:05] Yes it was but they "gave" it to phacility [22:26:10] the phabricator folks [22:26:22] ahh [22:26:57] #info https://github.com/phacility/xhprof is PHP implementation of xhprof [22:27:07] #info xhprof is built into hhvm [22:29:11] sounds like a plan? [22:29:34] yeah, just working out what the plan is exactly... [22:29:47] I guess retaining wfProfileIn but removing most of the calls to it [22:30:11] and additionally researching support for wfProfileIn in ProfilerXhprof [22:30:29] any objections to that? [22:30:34] i guess if someone feels up to poking at patching xhprof to allow sub.function / custom profiling points, that would be great ;) [22:30:47] yeah [22:30:56] And start with HHVM when you do that. :) [22:31:02] sounds reasonable, however do we have any information on third parties who use profiling? [22:31:26] not afaik [22:31:30] That's a good question. wikia mentioned it on the talk page for the RFC [22:31:39] But they aren't using master so ... [22:31:45] next topic? [22:32:04] #topic Ditch crappy API formats | RFC meeting | PLEASE SCHEDULE YOUR OFFICE HOURS: https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [22:32:13] #link https://www.mediawiki.org/wiki/Requests_for_comment/Ditch_crappy_API_formats [22:32:59] accept? :) [22:33:11] :P [22:33:31] So bd808 and I have been working on getting the api-feature-usage log into logstash, which should (1) let us more easily look at the usage levels of these deprecated formats and (2) https://www.mediawiki.org/wiki/API/Architecture_work/Planning#Deprecated_API_usage_report_on_WMF_wikis [22:35:40] you know yaml is an alias for json already [22:35:58] I'm very much in favor of reducing the number of formats we support [22:36:47] yep. that's why we should stop pretending we have yaml [22:37:20] maybe all the yaml requests are people looking for yaml and being disappointed [22:37:28] I don't think anyone's opposed to getting rid of these formats. The RFC wants to pick a specific date instead of the current rather nebulous plan of "let's keep an eye on usage levels". [22:37:31] "oh, it's just json" [22:37:37] 70k requests a day? :P [22:38:14] anomie, my point is that if we keep on waiting for zero usage, we will never achieve it [22:38:41] * mark whistles, plays with the routers [22:39:45] what format is "text/x-wiki" from? [22:39:50] yeah, I'm happy to approve that timeline for removal [22:39:52] i'd like to see a breakdown by user agent and ip [22:40:07] the number of clients is much more interresting than the number of requests [22:40:17] i.e. removal of WDDX, YAML, dbg and txt [22:41:00] a year from when the original deprecation announcement went out? [22:41:17] I proposed 6 months for WDDX [22:41:22] https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2014-August/000065.html Aug 15 [22:41:29] 6 months is fine for me too :P [22:41:33] yeah, but nobody uses wddx [22:41:41] more than generous [22:41:52] 6 months from june ;) [22:41:59] * aude wonders if these formats all even work still [22:42:13] TimStarling: well.... https://bugzilla.wikimedia.org/show_bug.cgi?id=71543 [22:42:38] format=text/x-wiki is curious. did that ever work? [22:42:48] In the API? No. [22:42:50] DanielK_WMDE_: no [22:42:59] 40k requests/day for something that never worked?... [22:43:06] does it fall back to something that does work? [22:43:16] now i'm really curious about the user agent strings :P [22:43:19] DanielK_WMDE_: that might go back to your clients vs requests things. could be one misbehaving client [22:43:21] 40k requests in a particular day [22:43:32] ebernhardson: indeed [22:43:38] hopefully that bug is fixed by now and whoever it was is not still sending 40k requests per day [22:43:47] but you never know [22:43:51] Exception Caught: Internal error in ApiFormatWddx::slowWddxPrinter: Unknown type NULL [22:43:52] TimStarling: yea, would be nice to see another couple of days, in case of outliers [22:43:52] https://en.wikipedia.org/w/api.php?format=aksdjhfdskjh&action=query goes to jsonfm [22:43:58] at least for wikidata.... [22:44:10] but kind of works though [22:44:28] "slowWddxPrinter"? [22:44:42] do we have "fastWddxPrinter" too? [22:45:00] heh... no idea [22:45:14] wddx_serialize_value() is the fast one [22:45:15] DanielK_WMDE_: There's an optional wddx implementation in PHP. [22:45:38] oh, could it be action=parse's contentformat parameter? [22:45:53] hm... [22:45:55] actually... [22:46:03] do we *really* want to drop wddx? [22:46:12] are you serious? [22:46:16] it's structurally much closer to JSON than to the XML rendering [22:46:47] so, if we want to get rid of all the quirks of format=xml, but want to be nice to people who love xml for some reason, wddx may be a way out [22:47:11] keeping xml and dropping wddx may be the wrong way, even if wddx is scarcely used right now [22:47:27] DanielK_WMDE_: The flaw in that plan is that people like the weird crufty XML format they're using, rather than the weird verbose XML format they're not. [22:47:44] xml is what is in the dumps, as you well know [22:47:56] nice to have the same format in the api, even if not nice [22:47:59] anomie: yea, i'm just wondering whether they would rather switch to wddx than to json. i dunno. [22:48:24] basically, what i'm saying is: i'd rather keep supporting wddx than our quirky xml format [22:48:26] aude, well, the API doesn't output the same XML structure as dumps;) [22:48:34] if we can drop both, so much the better [22:48:35] well, for the moment we are only talking about deprecating things that (almost) nobody is using, deprecating XML is more complicated [22:48:48] MaxSem: true... [22:48:49] what is the use case for it othter than the theoretical niceness? [22:49:03] you remember at the arch summit I suggested a number of ways for making deprecations be more noisy [22:49:09] aude: the indexedTagName stuff is reeeely nasty... [22:49:22] add payload so that people start noticing? [22:49:28] DanielK_WMDE_: perennial breaks... not just in wikibase [22:49:31] * anomie runs a grep to get usage counts for today from api-feature-usage.log, but it's slow. Mainly because everyone is hitting the "rawcontinue" deprecation, bloating the log. [22:49:56] 1 "format=dump" [22:49:56] 1 "format=wddx" [22:49:57] 2 "format=wddxfm" [22:49:57] 2 "format=yamlfm" [22:49:57] 3 "format=dbgfm" [22:49:57] 202 "format=txtfm" [22:49:59] 12152 "format=yaml" [22:50:01] 21084 "format=dbg" [22:50:03] 61659 "format=txt" [22:50:13] * aude has reported index tag bugs in other extensions and nobody cares apparently to fix [22:50:26] afaik [22:50:39] maybe we could have some system for preventing XML from being used in new modules? [22:50:41] * anomie is planning to fix ApiFormatXml to not throw index tag errors, one of these days [22:50:54] maybe an opt-in to XML when the API module is registered? [22:51:07] hehe, would be nice:P [22:51:23] Output format is mostly independent of which modules were run. [22:52:10] opt in would be nice [22:52:26] enough extensions are wmf only (pretty much) and don't have use case for xml [22:52:29] to have to maintain it [22:52:30] there's only one module in the action parameter [22:52:41] presumably you could decide whether to support XML based on that [22:52:52] But action=query and action=flow have submodules. [22:53:01] in theory, the module doesn't have to worry about the serialization format [22:53:07] with xml, it does, though [22:53:09] yeah, not for query submodules, they would just use ApiQuery's settings [22:53:22] just for entire actions [22:53:36] even then - in theory, they are oblivious to the output format [22:53:37] at some point, I started special-casing output in my extensions so that it looked sane both in XML and everything else, no "*". ughhhhhh [22:53:43] just doesn#t quite work for xml [22:53:50] MaxSem: Eew. [22:54:07] anomie: we ended up doing the same in wikibase [22:54:14] DanielK_WMDE_: Also eew. [22:54:18] which is why i really wnat to get rid of the quirkxy xml [22:54:39] anomie: the alternative would have been to make the json a lot hard to use [22:55:00] there are something like 90 actions now, on en.wp [22:55:20] what if we removed XML support from 80 of them? [22:55:35] nobody would notice [22:55:40] ...(almost) [22:55:57] a breakdown by module would also e interesting [22:56:03] seriously, stuff like cirrus-config-dump has to implement xml? [22:56:13] * anomie would assign all bugs related to such a thing to the people who pushed it through. [22:56:57] anomie: bugs like "bring back xml"? [22:57:53] ok, anyway, proposed deprecation schedule is approved, let's just archive that RFC [22:58:01] :) [22:58:07] still broken... [22:58:28] MaxSem: Are you going to send the notice to mediawiki-api-announce? [22:58:31] let's deprecate xml soon, and see how that goes ;) [22:58:41] anomie, yep! [22:59:29] #agreed RFC approved [22:59:59] DanielK_WMDE_, xml is less than 10%, I see no problems with derpecating it. let's say in 100 years:P [23:00:05] #info maybe an opt-in to XML when the API module is registered? [23:00:37] next week we are going to move this meeting one hour earlier [23:00:46] so that it's not so ridiculously late in europe [23:00:49] yay :) [23:00:54] :) [23:01:29] aude, mark - don't you guys don't ever sleep anyway? :) [23:01:32] this is basically a change for daylight savings [23:01:45] heh :) [23:02:17] we will presumably switch back in the northern summer [23:03:07] #endmeeting [23:03:07] Meeting ended Wed Nov 12 23:03:07 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:03:07] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-22.04.html [23:03:07] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-22.04.txt [23:03:07] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-22.04.wiki [23:03:07] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-11-12-22.04.log.html [23:03:39] TimStarling, I also revised https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction and would like to have it reviewed due to growing usage and allegations of server load - can it go next week? [23:06:19] mark can decide [23:06:21] I have another meeting now [23:07:57] MaxSem: we can swap it out for minifier if you want :) [23:08:17] the inifier I've abandoned? sure! :) [23:09:01]