[04:00:26] there is some suicide announcement in #wikinews [04:11:29] itu, what did he exactly say? [04:11:51] http://etherpad.wikimedia.org/p/ng76bOJlBo [04:13:59] not sure how he would post it after the act.. [18:43:55] Tech Talk: Design Research in Product Development by Abbey Ripstra will be starting in 17 mins. Link to follow along on youtube: http://www.youtube.com/watch?v=jYMTzzosUIw [18:54:31] Tech Talk: Design Research in Product Development by Abbey Ripstra will be starting shortly. Link to follow along on youtube: http://www.youtube.com/watch?v=jYMTzzosUIw [18:54:49] If you have any questions during the talk please ping me and I will ask Abbey for you [19:00:33] We will be starting in 3 min - just giving people a chance to settle in [19:03:39] the stream is starting [19:04:07] Mine is working. [19:04:22] great :) [19:12:50] is the sound OK? [19:12:55] yes [19:13:00] Sounds great [19:13:03] great [19:14:25] i object to that characterization of ethnography, by YMMV [19:15:40] Guerillero, which one. The proper ethnography or the design ethnography? [19:16:00] the proper ethnography [19:16:08] On what grounds? [19:16:15] * halfak is curious :) [19:16:27] my "village" is wikidata [19:16:52] Ahh yes. Digital trace ethnography. :) [19:17:20] http://www.stuartgeiger.com/trace-ethnography-hicss-geiger-ribes.pdf [19:17:31] Guerillero, I think she was just giving a "you may not be familiar with this word" generic definition. Extrapolation is implied! ;) [19:18:12] ya, I know. I am just being pedantic. [19:18:14] quiddity, the validity of digital ethnography is a hot topic in the field right now. [19:18:36] Extrapolation is always implied. ;_; and pedantry = clarity. :) [19:19:00] also, thank you for an article to add to my file for my lit review [19:19:10] halfak, ah, interesting. [19:20:42] Guerillero, I'm sure User:Staeiou (first author) would love to talk about the work. [19:28:09] "in the wild" :) [19:35:46] almost time for questions [19:35:51] let me know if you have any [19:36:34] Q: Does the design research team engage in "blue sky" research -- research for the sake of building understanding that doesn't have an obvious & immediate use for a product? [19:36:40] Q: How are you do you account for users who are hard to reach due to distance, language, timezone, etc? Are we designing Wikipedia for Western English-speakers because it is easy? [19:37:10] I have more too if we have time. :) [19:37:33] I'll just post them here, but use your judgement, rfarrand. [19:37:45] additional Q: Do you see "design research" as based primarily on qualitative methodologies or can someone be a design researcher while specializing in quantitative methods? [19:37:47] * halfak claps [19:38:24] * Guerillero claps [19:38:27] additional Q: What's the future of ethnographic methods in design research? Do you guys plan to make time for "becoming Wikipedian" in order to more effectively understand your users? [19:38:34] * quiddity claps [19:41:32] last chance for qs! [19:42:56] very informative. Thank you [19:43:01] * halfak claps again [19:43:05] Thanks for coming everyone! [19:43:07] * Guerillero claps [19:43:14] I will post a link to the video on wikitech-l later today [19:43:20] now for rugby [19:43:47] in case you missed anything or would like share it around [21:01:25] #startmeeting RFC meeting [21:01:25] Meeting started Wed Oct 22 21:01:25 2014 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:25] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:25] The meeting name has been set to 'rfc_meeting' [21:01:49] #topic Scoped language converter | RFC meeting | 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/ [21:02:40] cscott: are you here? [21:04:00] TimStarling: He says he's finishing up a deployment, so maybe we can do his thing second? [21:04:06] yep [21:04:26] #topic HTML templating library | RFC meeting | 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/ [21:04:43] who wants to talk about HTML templating? [21:05:10] I can chime in a bit [21:05:36] Basically Jon is working on putting together a patch for core that introduces a ResourceLoaderFileModule feature [21:05:44] TrevorParscal: the patch is done [21:05:47] https://gerrit.wikimedia.org/r/#/c/167342/ [21:05:48] for specifying templates that can be sent to the client [21:06:00] we've been reviewing it a bit and steering that work [21:06:03] but that's just step 1 [21:06:24] step 2 is updating the RFC and coming up with a patch that introduces an actual template processor [21:06:30] for both the client and the server [21:06:40] so the same templates can be rendered on either [21:06:52] that patch and changes to the RFC have not happened yet [21:07:04] i have asked the ui folks in the wikidata team about html templating. we are using our own extremely dumb system at the moment. [21:07:14] and the changes to the RFC are meant to reflect the new position on which language to adopt [21:07:20] consensus seems to be "whatever they come up with, just stick to something". [21:07:29] and "handlebars seems fine" [21:07:36] I believe the direction is "something to do with Mustache" [21:07:40] TrevorParscal: sorry for cutting in [21:07:45] i also lean twords handlebars, but i think you know that :) [21:08:00] Mustache being logicless, and other Mustache-based things being Mustache + logic [21:08:09] i'm really not interested in rewriting a bunch of things in php and javascript, and having some semblance of logic in the template makes alot of that possible [21:08:20] spiff [21:08:22] Flow is using a lot of logic in templates, Mobile front-end is not [21:08:28] do we plan on compiling templates serverside and then using them clientside with RL? [21:08:44] please no turing complete templating... [21:08:54] legoktm: That should be at least possible, if not the default way of doing things [21:08:59] lua in the browser ;) [21:09:02] DanielK_WMDE: handlebars isnt, thats twig for turing complete [21:09:06] ebernhardson: but with helpers you implement them both in php and js already.. how is that different from doing this in functions before template rendering? [21:09:08] (seriously though: no lua in the browser.) [21:09:10] hehe [21:09:12] I am also against logic in templates in general, and leery about exceptions [21:09:17] I like logicless templates [21:09:42] simple if/else and loops don’t bother me [21:09:51] jdlrobson: those helpers arn't really the logic i'm thinking about, i mean how the templates use logic to assemble themselves. If you can't even use an equality statement you need to have code pre-assemble data on both sides [21:09:52] but templates should generally not be too crazypants [21:09:56] BTW, for context: Jon's current patch deliberately uses HTML as a templating language to sidestep this whole discussion for now. As in, it just delivers HTML blobs to the client [21:10:06] btw, i hear that processing templates with a JS processor on the service side is faster than any php implementation, and avoids inconsistencies [21:10:16] RoanKattouw: exactly, which is why it's a good step 1 [21:10:19] even with the inter-process overhead, it seems to be *really* fast [21:10:24] RoanKattouw: but it is also wired up to use Handlebars or Hogan [21:10:24] and, we also want to remain language agnostic [21:10:26] oh nice! [21:10:28] (i think the guys were using rhino, but i'm not sure) [21:10:37] so, we can detect the template language based on the file extension [21:10:46] DanielK_WMDE: There's a bunch of benchmark stuff in that RfC already I think, but feel free to add data points [21:10:57] and support more than one in the future, at least for transitional purposes - should we realize we chose poorly down the road [21:10:59] i wanted to make a generic RL module so 3rd parties can use other template languages if they want to (i like fostering innovation by making an overly restrictive system) [21:11:13] RoanKattouw: would have to ask, this is a story from outside the wiki-world [21:11:17] just food for thought [21:11:35] grr grr [21:11:48] RoanKattouw: really those benchmarks arn't big enough to convince me of much, some of those benchmarks compile down to: return "foo bar $baz"; [21:12:13] actually, allowing more than one language ight be problematic because you lose the synergy from having everyone use the same engine [21:12:23] so, where are are, it appears that the architecture team is wanting the RFC to be updated and for there to be a reviewable patch to core that adds the template processor(s) [21:13:03] TrevorParscal: yep, we’re pretty happy with the basic idea and it sounds like implementation is continuing well [21:13:21] just want to make sure it gets finished out [21:13:27] MaxSem: I think the idea is that the RL delivery system is language independent, but there will be only one template compiler thing in core [21:13:32] I don't really want RFCs to be eternal design documents in some field of responsibility, I want them to be completable [21:13:47] legoktm, yup - core should set a standard [21:13:55] MaxSem: what legoktm said [21:13:59] hence why i said 3rd parties [21:14:02] to distinguish from Wikimedia [21:14:15] so maybe just add a section to the RFC that says "we choose mustache", then we can mark it accepted [21:14:20] aaaah office hours [21:14:25] :P [21:14:25] TimStarling: sounds about right [21:14:29] hey aude [21:14:33] I hope that we can choose a very restricted set of features for the core templating library (like vanilla mustache) [21:14:38] * aude always forgets until halfway in or until after [21:14:51] because otherwise we may quickly regret it, and wish we could get the toothpaste back in the tube [21:14:53] so there will be a mustache processor in both PHP and JS? [21:14:58] but we could always add more features over time [21:15:18] I think there was some mention that Handlebars can be wired up so that helpers are disabled [21:15:28] TimStarling: yes [21:15:32] http://mustache.github.io/ [21:15:47] It's very cross-language compatible [21:15:51] since MobileFrontend is using Hogan any mustache based language should work for us [21:16:25] so I guess you will pull both of them into core with composer? [21:16:38] flow uses https://github.com/zordius/lightncandy which implements both handlebars and mustache https://github.com/zordius/lightncandy [21:16:58] mustache.php (linked from the github page) has composer support, yes [21:16:59] TimStarling: that's the idea, yes [21:17:17] lightncandy also includes a fairly well fleshed out compatability test that runs it and the javascript version, and asserts equal output for equal input [21:17:32] ebernhardson: that's cool [21:17:34] is anyone opposed to the idea of making mustache the recommended template processor for MW core and extensions? [21:18:03] does csteipp agree to it? [21:18:18] we also plan on templates exported to the client to be namespaced by the module they were bundled with, such that we would have an interface sort of like mw.template.get( moduleName, templateName ) [21:18:18] I remember I thought the i18n handling from lightncandy (flow) made sense... can that be done in handlebars? [21:18:43] let me put it another way [21:18:51] this way we can avoid name collisions, and move toward the eventual encapulation of all module-resources and use CommonJS modules on the client [21:18:54] In general, I like logicless though, so I'd rather do handlebars if it's not going to cause every team to do ugly hacks that make their code unreviewable. [21:19:08] s/mustache/handlebars/ [21:19:28] should we approve mustache now in this meeting, or should we push it back for further discussion? [21:19:53] I believe we can and should choose vanilla mustache immediately [21:20:02] +1 [21:20:06] I'm good with that [21:20:07] csteipp: you mean you'd rather do mustache? [21:20:07] i'd say we can approve it in principle, pending review of the concrete implementation [21:20:13] Sounds fine to me [21:20:15] (other things should be available extensible in an extension if they really want it) [21:20:16] your regex substitution got no matches [21:20:18] stuff like i18n may warrant further investigation, though [21:20:31] TimStarling: Yes, I'd prefer mustache in general, as long as that doesn't mean teams do ugly hacks.. etc. [21:21:01] ok, that sounds like consensus to me [21:21:13] \o/ [21:21:16] let me just edit the wiki page [21:21:21] jon, can you update the RFC? [21:21:22] +1 \o mustache [21:21:37] * aude cheers! [21:21:38] :{ [21:21:45] TrevorParscal: if you help me get https://gerrit.wikimedia.org/r/#/c/167342/ merged today [21:21:52] you've got all my attention on that patch and I want it off my back :) [21:21:58] jdlrobson: sounds fine to me [21:22:01] ok cool [21:23:16] RFC updated: https://www.mediawiki.org/w/index.php?title=Requests_for_comment/HTML_templating_library&diff=1235476&oldid=1225624 [21:24:15] jdlrobson: RoanKattouw and I are reviewing it now [21:26:52] * cscott pops in [21:27:18] next RFC? [21:27:40] #topic Scoped language converter | RFC meeting | 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/ [21:27:42] TrevorParscal: i don't like vanilla mustache, for the record [21:28:00] cscott: can you elaborate? [21:28:18] * DanielK_WMDE preferrs strawberry [21:28:25] the meteor project has a slightly-forked version which handles some things better. in particular it ensures that tags are properly nested, meaning the output will never be terrible string concat jumble. [21:28:59] and gwicke and i actually worked on a handlebars port with these same semantics a couple of months ago, using his backend engine. [21:29:05] sounds slower [21:29:13] it was significantly faster [21:29:27] gwicke can elaborate, probably. maybe if i mention him he will appear. [21:29:38] cscott: if it's compatible and has both PHP and JS implementations, then we can switch to it without issues at any time, yes? [21:29:46] i haven't caught up on backlog here, so i'm probably missing some of the context for this RFC. [21:30:01] yeah if it is only slightly forked then we can consider it at another time [21:30:10] assuming the syntax is compatible [21:30:11] but to me the important thing is that HTML tags be generated properly nested, so we don't need some weird tidy pass afterwards to clean up the mess [21:30:30] why not do the right thing from the beginning? [21:30:42] otherwise we end up generating broken html in various ways without noticing [21:30:42] does the library have PHP and JS implementations? [21:30:54] gwicke's implementation does [21:30:55] and is it actually compatible with Mustache? [21:31:03] or is it yet another syntax? [21:31:08] i'm not sure it's ready to drop in use yet -- like i said i'm not caught up on the context here. [21:31:11] because it's been many many months and a lot of people just want a decision [21:31:27] keep it simple :) [21:31:47] cscott: I think the ideal move would be to adopt mustache today, and consider replacing it with something compatible but more robust later when and if that thing is ready for adoption [21:32:14] well first, why not handlebars? http://handlebarsjs.com/ [21:32:24] (personally i’m happy with html templates and DOM replacement, but everybody loves the mustache-esque ones) [21:33:14] and meteor's implementation is actually called 'spacebars' -- again, largely compatible, but with some important semantic differences in the details that i think it's important to get right from the start [21:33:43] cscott: we want to avoid starting out with a template language that introduces logic [21:34:13] cscott: maybe you should read the backscroll [21:34:17] sorry, i'm really unprepared for this discussion [21:34:44] i was actually working on a template library integrated with scribunto a while ago as a spare time project. [21:35:19] i hate to see a solution adopted just because it's the easiest things that's not entirely wrong, but i also don't want to be the person standing in the way of all those trying to get work done. [21:35:37] * brion cites ‘worse is better' [21:35:58] cscott: i think the idea was to adopt a very dumb baseline, and then take it from there. i think that baseline was supposed to be mustache. [21:36:03] brion: yes, but you don't have to deal with broken wikitext markup every day [21:36:13] fair enough :) [21:36:37] our project is inherently a knowledge creation project, and having that knowledge being created in ways that we ultimately can't use (or have to rewrite) is a real drag. [21:36:53] i think going for something very limited but well defined, with good extension points and multiple implementations makes sense [21:37:15] i can probably sign off on a dumb mustache baseline. like i said, i think you can do much better -- but the much better thing ends up *looking* a lot like mustache [21:37:20] especially the dumb parts of it [21:37:48] it *would* be nice to consider whether the output could be linted or tags closed or some such from the start, so people don't start writing templates that will eventually be broken. [21:37:50] about 15 minutes ago, mustache was approved by brion, csteipp, TrevorParscal and RoanKattouw [21:38:01] and DanielK_WMDE [21:38:08] i notice that the parser team isn't represented there ;) [21:38:19] parser team doesn’t have to parse UI :) [21:38:20] the parser folks *really* like for the resulting output to be well-structured. ;) [21:38:21] I asked for objections and there were none [21:38:49] oh, if we're talking UI only, ignore me then! i'm sorry. [21:39:09] yes, only for UI [21:39:16] again, i apologize for coming in unprepared. [21:39:18] In the long term it would probably be nice to have consistency between the two, so it's not a great excuse. But yes, we were only talking about UI stuff [21:39:18] ok then i think we can say we have a decision :D [21:39:34] even for UI i think that structured output is better, but i think we can get there from here. [21:39:41] *nod* [21:39:50] for non content, i'm less worried about people abusing the template system to play evil html tricks [21:40:02] in theory gerrit will prevent that ;) [21:40:07] there's not any proposal for exposing HTML templating to end users [21:40:11] none that I'm aware of [21:40:12] I would have preferred to instead approve a DOM-based templating solution (also for security reasons), but the credible solutions for that are all vaporware to various degrees [21:40:42] TimStarling: system messages will do that sooner or later [21:40:43] RoanKattouw: yeah, that's another subtle semantic difference w/ spacebars as opposed to plain-old-mustache [21:40:44] TimStarling: There is something that implies user-visible HTML templating on the Parsoid roadmap [21:40:51] RoanKattouw: yeah, would love to see something once it’s more solid. that can be driven by an extension team that needs it when it’s ready to do the work [21:40:57] mustache is a string concat engine, so it brings with it all the escaping mess [21:41:06] But yeah I have string concat engines as much as you do [21:41:14] once you actually are building dom trees properly instead, the escaping happens correctly and magically for free, more or less [21:41:17] But I also like things that are available and work and that people are working on [21:41:57] I would love to live in a world where there is a DOM-based templating solution for which those things are true, but AFAIK that's not the case yet [21:41:59] well, i was working on templating, as was gwicke. but we're also working on very many other things. ;) [21:42:04] Yeah exactly [21:42:09] You guys are spread pretty thin right now [21:42:24] And in 6 months or a year there probably will be a credible DOM-based alternative [21:42:25] anyway, https://github.com/meteor/meteor/blob/devel/packages/spacebars/README.md is more or less the spec for the new hotness [21:42:31] cscott: how about a generic dom transformation engine written in haskel ;) [21:42:36] +l [21:42:50] But right now there isn't really one, and we need to move on with our lives at least for the time being [21:42:54] Speaking of moving on [21:42:56] :) [21:42:56] in particular the section labelled 'html dialect' [21:43:09] We have now burned almost half the time dedicated to cscott's scoped language RfC on templating stuff [21:43:16] Shall we talk about the language converter stuff? [21:43:27] well, i wasn't aware that we were talking about that today [21:43:53] Hah [21:43:56] so we can talk about it, i guess. but i'm still going to be the donkey in the room. [21:44:02] There was an announcement but I guess we neglected to specifically reach out to you? [21:44:11] I sent a meeting invite [21:44:28] did i accept? ;) [21:44:41] you were on vacation [21:44:48] I took your silence as assent [21:45:13] ah, that would explain it. sorry. [21:45:16] cscott: i added a not a few minutes ago pointing to the ContentHandler mechanism for managing glossaries as pages ina a sane ways. [21:45:28] my inbox was rather full when i got back, there were a few ocg fires that i'm still working on. [21:45:29] doesn't really impact your proposal. just something to keep in mind when implementing it [21:45:47] i'm certainly interested in general discussion [21:45:57] anyway, scoped language converter, is that a thing you want and what do you need for it? [21:46:02] the current plan of record is for me to implement basic support for variant markup in parsoid this quarter. [21:46:23] but no one @ wmf seems to be very happy with actually using language converter on real wikis [21:47:07] the general consensus from those who don't speak one of the affected languages is that it is too much complexity, and the wikis should be split instead. [21:47:29] the RFC is an attempt to improve language converter, but i don't think it's safe to say that there is a consensus that language converter should be improved [21:47:31] cscott: variant markup is the special syntax that gets all variants into the parser cache, and then mangles the output to pick one upon pageview? [21:47:33] well, I don't agree with that [21:47:40] cscott: wikidata needs it. [21:47:42] general consensus minus me [21:47:49] well, minus me as well [21:48:09] I don't agree with splitting the wikis either [21:48:34] variants is pretty important for chinese, for example [21:48:34] So, my understanding from speaking to cscott and David Chan about this earlier is that there are some horrible things in LC that can be fixed without affecting real-world use cases? [21:48:41] i love the idea of language converter, its implemenatino just scares me ;) [21:48:43] a proper solution would involve a decent amount of VE work in order to allow users to edit articles in their native variant. [21:48:44] i don't think splitting is a good solution [21:48:52] cscott: i for one am very interrested in good support for multilingual wikis like commons and wikidata [21:48:56] brion: so you don't agree with the idea of splitting the chinese wiki? [21:49:03] TimStarling: i like keeping em together [21:49:09] language converter isn't "multilingual", really. [21:49:10] but then i’m not in the affected community [21:49:15] #agreed don't split the variant wikis [21:49:36] it's more multidialect -- it's an ease of maintenance thing, to allow languages which are "close enough" to share the same wiki and just store the diffs between the languages, more or less. [21:49:53] cscott: for multilingual wikis we may still want LC to handle those languages like zh, sr, etc [21:50:09] in which case making it pluggable per-page-language is nice [21:50:25] i'm back - reading backlog [21:50:29] anyway, why don't we pretend that there is resourcing to actually make language variants work well and discuss how you'd do it. [21:50:54] cscott: automatic transliteration is quite helpful for multilingual projects, though. i'm not expecting automated translation. [21:50:54] so there are two main things that are scary about current LC. well, let's say three. [21:51:24] more than half our content is places and people. proper names. no translation needed. [21:51:25] starting with the fact that it's written and maintained by zhwiki folk and historically the 'good' documentation has all been in mandarin, so SFO folks are a little afraid of it. [21:51:35] putting that aside, the two technical issues are: [21:51:57] I've reviewed pretty much all of the conversion code and have been involved with various technical details over the years [21:52:14] I have worked with successive chinese developers [21:52:21] 1) rules are defined to take effect starting from their declaration site and affecting the rest of the page, leaking out of templates, etc. this means that a LC rule inside a template can have unpredictable effects on the rest of the page. [21:53:07] TimStarling: I'm not saying that the fears are justified. and i've worked with liangent and gotten most of the good docs translated. i'm just pointing out that there are social factors as well as technical factors. [21:53:13] * aude notes https://bugzilla.wikimedia.org/show_bug.cgi?id=19044 (Document LanguageConverter) [21:53:30] cscott: have you asked liangent for input? she seems to be the expert on the chinese side of things. [21:53:52] luckily for technical factor #1, the *actual way that LC rules are used* is in glossaries which are included at the top of the page. So we can make a change like the RFC in question and have a chance of migrating the existing content w/o too much pain. [21:53:59] we're almost out of time now [21:54:15] hm, too slow, i was. [21:54:16] the main proposal is to introduce this glossary feature [21:54:25] so this rfc is mostly about #1 [21:54:29] I like the feature proposal but I am not sure about the namespace name [21:54:43] since I would also like to have a mouseover glossary feature at some point [21:54:56] technical issue #2 is that the language converter is shoehorned somewhat awkwardly in the parse process, so it interacts poorly with other wikitext constructs. [21:55:13] i hope to address some of that in conjunction with my parsoid work this quarter. but that's outside this rfc. [21:55:54] particularly https://www.mediawiki.org/wiki/Extension:Lingo [21:55:54] anyway, i'm afraid that i've mostly been unconstructive here, and i feel bad about that. [21:56:22] I want to have Extension:Lingo on WMF wikis, with a few little changes for scale [21:56:35] e.g. not having all the definitions for the whole wiki on a single page [21:56:41] for the record, I'd like to see the application of glossaries *not* use the template transclusion mechanism [21:57:51] "glossary" would be a reasonable name for a Lingo namespace, yes? [21:58:55] anyway, it probably doesn't matter what the english name for it is [21:59:05] since obviously we're not going to use it in english [21:59:10] that seems like its bikeshedding a bit, but i'm happy to consider other namespace names. i'd expect that the name would be localized for zhwiki anyway. [21:59:15] yeah. [21:59:17] maybe ask the chinese people what they call the system [21:59:51] although i *would* like to enable language converter to translate american english to british english, even if just on a beta/labs wiki, so that more english-speaking devs can use the system and understand it. [21:59:59] I'm not bikeshedding, I'm saying I am fine with the general idea and I am giving feedback on the details [22:00:11] bikeshedding is when you block the proposal for the sake of the details [22:00:36] cscott: liangent once implemented a piglatin translator. i liked it a lot for testing, but it wasn't accepted... [22:00:39] * DanielK_WMDE wants it back [22:00:48] obviously you are not prevented from implementing this pending a decision on the namespace name [22:02:35] gwicke has a variant of this proposal, at https://www.mediawiki.org/wiki/Requests_for_comment/Page_and_category_based_language_variant_conversion [22:02:55] category based?.... ick. [22:03:03] the main difference is that he doesn't think there needs to be explicit wikitext markup for the glossaries [22:03:19] it's part of the page metadata, like interwiki language links are now [22:04:00] at the time i objected, because separate page property storage appeared to be in the far future. but now it's looking like we might be able to skip having dedicated wikitext markup for this after all. [22:04:04] maybe using wikidata or some such [22:04:39] it would be worth fleshing out that option more fully [22:04:55] I think we should talk about this in another meeting [22:05:10] cscott: there's also https://gerrit.wikimedia.org/r/#/c/72053/ [22:05:10] cscott: metadata attached to the üproper article content is something we have been discussing with ewrik and the multimedia team, for commons meta data. [22:05:17] it's on the roadmap for the next 6 months. [22:05:20] I think I should write some comments on the RFC talk page [22:05:39] well, not fixed yet. but it's there. I'll likely work on this quite soon [22:05:55] oh, you've already commented on that :P [22:06:01] yup ;) [22:06:06] legoktm: yea, i want that :) [22:06:26] anyway, i think this rfc is a bit stalled because it's waiting on higher level arch guidance [22:06:43] on the storage aspect? [22:07:40] on the storage aspec, it should definitly not be in wikitext in any way. it should either be page metadata, or on a separate page, in both cases using an appropriate content model [22:07:43] to wit: how do we want to support this in VE, whether we want to expand data storage outside wikitext formats, what sorts of editing experience do we want (and whether these variants should be sharing a wiki in the first place, as opposed to using some souped up Language Translation feature) [22:07:50] DanielK_WMDE: so how is it edited? [22:08:01] DanielK_WMDE: are glossaries in the mediawiki namespace? [22:08:04] cscott: if it's a text based format, as text [22:08:16] are they lists of rules in wikitext, or are they all stored in the wikidata space somehow? [22:08:18] if not, then it'S up to you. wikidata uses specialized api modules [22:08:34] cscott: no, it has nothing at all to do with wikidata. it has everything to do with contenthandler [22:09:01] you can defined handlers for any kind of text, and any kind of other data structure [22:09:11] my point is just that is would require that somebody write a new editor. things which are wikitext get an editor "for free" [22:09:27] cscott: all things that are text can share that editor [22:09:31] #info needs comments on VE integration and storage [22:09:49] indeed, we already support non-wikitext content via the standard editor: JavaScript, Css, and Lua [22:09:54] probably CVS soon [22:10:14] Brad was showing me JsonContentHandler the other day [22:10:28] cscott: if you want something that is not text based, then you need a dedicated editing ui. may or may not be worth the trouble, i don't know [22:10:34] he integrated it with SecurePoll with a few lines of code, and the UI looks pretty nice [22:10:51] TimStarling: i'm a bit dubious about that, because JSON isn't really nice to edit as text. but yea. [22:11:07] oh, this is for uneditable pages [22:11:21] thne JSON should be the storage format, not the content model ;) [22:11:25] but we digress. [22:11:38] so if that's the new hotness, then you don't want an rfc documenting a Glossary namespace and a wikitext format for scoped rules, you need an rfc documenting the... 'content model', i guess? [22:11:59] i would love to work with someone to write that proposal, but i'm a bit out of my depth [22:12:18] cscott: yes. binding it to a namespace is fine (that's the default way to do content handlers), but a file extension or some such would also work [22:12:34] page-level metadata isn't here yet, but will be implemented soo, i expect [22:13:17] yes ContentHandler is super hot right now [22:13:35] cscott: if you have questions about countent models / content handler, poke me about it, i'm happy to add my 2c. i can't promise to co-author a full rfc though [22:14:14] TimStarling: i really want to get html-based transcusion going, that would make stuff like the graph extension *really* awesome. [22:14:30] * DanielK_WMDE was going to write an rfc for that [22:15:10] an RFC would be good [22:15:28] anyway, I guess we are done with this meeting now? [22:15:39] #endmeeting [22:15:39] Meeting ended Wed Oct 22 22:15:39 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:15:39] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-22-21.01.html [22:15:39] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-22-21.01.txt [22:15:39] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-22-21.01.wiki [22:15:40] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-22-21.01.log.html [22:15:58] TimStarling: yea... i'm still poking at how to best pass parameters to templates that are not wikitext. perhaps i'll mail you about that [22:16:06] i [22:16:54] anyway. past midnight here. see ya all in the morning! [22:16:56] i'm still so way behind on this conversation. i just noticed that i'd already updated https://www.mediawiki.org/wiki/Requests_for_comment/Scoped_language_converter to strip out all the specific wikitext markup for rules. [22:17:16] ttfn [22:18:11] anyway, i apologize again for being so scattered on this. my current schedule has me context-switching to language converter stuff next month. i'll hopefully have more paged in and can have more productive discussions there. [22:18:55] no problem cscott, thanks for coming [22:19:10] and if anyone wants to chat about template systems, i'm eager. in particular, i'd love to get a quantum to resurrect scribunto/js and finish prototyping my spacebars implementation there. [22:19:53] scribunto really needs to be more friendly to languages other than lua first, alas. [22:21:33] (in particular i was about to start working on some patches to allow both javascript *and* lua to be present in the same mediawiki, with some mechanism to determine which engine to use. maybe once we have page properties it will be straightforward to add a language tag to the scribunto script)