22:00:43 <TimStarling> #startmeeting RFC meeting
22:00:43 <wm-labs-meetbot`> Meeting started Wed Nov 30 22:00:43 2016 UTC and is due to finish in 60 minutes.  The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:43 <wm-labs-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:43 <wm-labs-meetbot`> The meeting name has been set to 'rfc_meeting'
22:01:20 <TimStarling> #topic RFC: Per-language URLs for multilingual wiki pages
22:01:43 <DanielK_WMDE> hi all!
22:01:54 <DanielK_WMDE> #link https://phabricator.wikimedia.org/T114662
22:02:03 <DanielK_WMDE> #link https://phabricator.wikimedia.org/E384
22:02:13 <DanielK_WMDE> So, super brief synopsis:
22:02:37 <DanielK_WMDE> Need: we want anon visitors to browse Wikidata and other multilingual wikis in their language
22:02:45 <DanielK_WMDE> Problem: Serving different renderings for the same URL messes with web caches.
22:02:54 <DanielK_WMDE> Solution: Force uselang based on some part of the URL path, similar to how language variants are handled
22:03:33 <DanielK_WMDE> so the idea is to server english from a path like /wiki-en/Q123 and french from /wiki-fr/Q123
22:03:53 <subbu> o/
22:03:56 <DanielK_WMDE> the language code in the path would force the interface language via uselang, which on wikidata also causes the content to be generated in that language
22:04:08 <DanielK_WMDE> first question:
22:04:17 <legoktm> wasn't there originally an idea to use code.wikidata.org/wiki/Q### kind of url structure?
22:04:30 <DanielK_WMDE> yes, that was the first idea.
22:04:38 <DanielK_WMDE> we can also go with that if it's easy enough to do
22:04:39 <YairRand> Q: would /w/... become /w-en/... etc?
22:04:51 <DanielK_WMDE> i think there were concerns regarding using subdomains, because of cookie domains and stuff
22:04:53 <DanielK_WMDE> is this a totally silly idea, or something we'd likey want to support?
22:04:58 <DanielK_WMDE> YairRand: no.
22:05:07 <DanielK_WMDE> YairRand: /w/ is the resource path, that would not be language specific
22:05:43 <TimStarling> "other multilingual wikis" = commons? meta? mediawiki.org?
22:05:47 <DanielK_WMDE> legoktm: i think subdomains look prettier, but are more tricky to get right. a rewrite based on the path is pretty simple.
22:05:50 <YairRand> so, would anons editing and whatnot just not get localized pages?
22:06:02 <legoktm> DanielK_WMDE: right.
22:06:05 <MaxSem> mhm, existing variant wikis use a slightly different schema, e.g. /wiki/ is default, /langcode-variant/ for variants
22:06:20 <legoktm> We currently have a gadget for Commons and Wikidata that does this right?
22:06:30 <DanielK_WMDE> TimStarling: Commons mostly. Things that use {{int}} and {{LanguageSwitch}} or whatever it's called would benefit. Things using Translate-style subpage would not yetg.
22:06:43 <DanielK_WMDE> I'd also like to do that, for mw.o and meta, but that takes more thought and more work
22:07:16 <legoktm> Isn't Commons transitioning over to E:Translate though?
22:07:27 <DanielK_WMDE> YairRand: oh, you mean when using an "ugly" path for editing, /w/index.php?title=...action=edit?
22:07:30 <legoktm> https://commons.wikimedia.org/wiki/MediaWiki:AnonymousI18N.js
22:07:40 <YairRand> DanielK_WMDE: Yes
22:07:43 <subbu> DanielK_WMDE, reading through the two rfcs (lang variants and uselang one), one concern was whether there would be a default url for a default rendering vs. forcing all reads to have a lang component always
22:07:48 <DanielK_WMDE> YairRand: good question. I hadn't though of that. maybe we *do* need /w-en/ etc for that case.
22:08:02 <subbu> i think niklas raised that.
22:08:11 <DanielK_WMDE> #info YairRand notes that we may need /w-en/ etc too, for action=edit at least
22:09:00 <DanielK_WMDE> MaxSem: Variants modify content language. I'm talking about user language. I'd love to combine them somehow, but that needs more thought
22:09:16 <DanielK_WMDE> subbu: ah, thanks for mentioning Nikerabbit's RFC
22:09:19 <DanielK_WMDE> #link https://phabricator.wikimedia.org/T149419
22:09:40 <DanielK_WMDE> there is a competing RFC --^  that proposes to allow anons to select language, but not encode it in the url
22:09:54 <DanielK_WMDE> the proposal is to split the cache based on a language cookie instead
22:10:05 <MaxSem> DanielK_WMDE, it affects UI laguage too
22:10:09 <DanielK_WMDE> iirc that'S not easy, but possible, with varnish
22:10:48 <DanielK_WMDE> MaxSem: The interaction is... confusing. I'd live to sit with you and cscott and discuss how to integrate those things.
22:11:14 <DanielK_WMDE> MaxSem: when we first discussed this rfc, i wanted to solve that problem at the same time. I now decided to narrow the scope, and focus on user language as needed by wikidata
22:11:46 <TimStarling> for simplicity we can probably assume that commons is a different problem also
22:12:00 <DanielK_WMDE> subbu: re default path for a default language: i think that when we first try this, the default path should stay as it is now. eventually, the default path can trigger a redirect to the apprpriate language path
22:12:11 <subbu> wfm.
22:12:17 <DanielK_WMDE> TimStarling: yes. for now, let's just focus on wikidata
22:12:44 <DanielK_WMDE> TimStarling: so, for wikidata, i want the language in the url. reasons:
22:12:54 <DanielK_WMDE> bookmakrs, links, and separate indexing by google
22:13:07 <DanielK_WMDE> can't be done with cookies
22:13:33 <DanielK_WMDE> #info <DanielK_WMDE> subbu: re default path for a default language: i think that when we first try this, the default path should stay as it is now. eventually, the default path can trigger a redirect to the apprpriate language path <subbu> wfm.
22:14:13 <DanielK_WMDE> #info we can use subdomains instead of pathes, but it's probably harder to get right
22:14:42 <DanielK_WMDE> #info competing RFC T149419 proposes to split the cache on a cookie, instead of the url.
22:14:43 <stashbot> T149419: Interface language selection for unregistered users on Wikimedia projects - https://phabricator.wikimedia.org/T149419
22:14:52 <DanielK_WMDE> ok. second question:
22:15:15 <DanielK_WMDE> if we cache separate renderings (language versions) of a page into the cache, how do we purge them when the underlying data changes?
22:15:43 <bd808> I think there's a hook? /me looks
22:15:47 <DanielK_WMDE> varnish 4.1 has xkey. looks to me like it should do the trick.
22:15:48 <subbu> DanielK_WMDE, wait .. subdomains? weren't subdomains frowned upon when we discussed the lang. variants proposal? Or, is this only a solution for wikidata?
22:15:52 <TimStarling> how does XKey work/not work exactly?
22:16:19 <DanielK_WMDE> TimStarling: when serving the page, you set xkey headers. the cache entry gets "tagged" with the xkey.
22:16:45 <DanielK_WMDE> you then need a custom rule for purging those. e.g. by sending PURGE with a GET param xkey=Foo
22:17:10 <TimStarling> sounds pretty simple
22:17:11 <DanielK_WMDE> you rule would then call the xkey purge function (whatever it is called internally)
22:17:17 <DanielK_WMDE> yes. let me find a link...
22:17:29 <DanielK_WMDE> #link https://github.com/varnish/varnish-modules/blob/master/docs/vmod_xkey.rst
22:18:01 <DanielK_WMDE> TimStarling: and you can send as many xkey headers as you like. one for each template used, maybe
22:18:38 <DanielK_WMDE> xkey is apparently already installed on the wmf cluster. but i'm not sure there's a rule for purging
22:18:52 <DanielK_WMDE> TimStarling: what would be the steps for getting this deployed?
22:19:01 <DanielK_WMDE> how would be best test the functionality of xkey?
22:19:22 <TimStarling> well, you can presumably test locally or on labs or whatever
22:19:28 <DanielK_WMDE> #info vernish xkey could be used to purge all language versions (renderings) of a page in one go
22:19:45 <DanielK_WMDE> TimStarling: sure. I was thinking of trying it with a small scale feature on the life system
22:20:04 <DanielK_WMDE> before making a big project depend on it
22:20:10 <DanielK_WMDE> i'll thing of something...
22:20:22 <TimStarling> we already purge half a dozen URLs when article text changes
22:20:36 <TimStarling> that's not a small project though :)
22:20:39 <gwicke> not at the same time, though
22:20:42 <DanielK_WMDE> heh
22:20:56 <gwicke> most are triggered by async updates, and can't easily use xkey
22:21:03 <DanielK_WMDE> but we could have an option to use xkey for this. and enabled it on a small wiki
22:21:12 <TimStarling> yes
22:21:13 <DanielK_WMDE> gwicke: why can't they?
22:21:46 <DanielK_WMDE> #info perhaps could have experimental option to use xkey for regular page purges, and enable it on a small wiki
22:22:24 <DanielK_WMDE> actually... wikidata also needs to purge JSON and RDF renderings of an item on top of the HTML. We could also try using xkey for that
22:22:25 <bd808> DanielK_WMDE: there are several open tasks like T122867 about using xkey once bblack says that Varnish 4 is ready to start using that
22:22:25 <stashbot> T122867: Evaluate the feasibility of cache invalidation for the action API - https://phabricator.wikimedia.org/T122867
22:23:11 <bd808> not the least of which is thumbnails
22:23:22 <DanielK_WMDE> bd808: i thought xkey is ready to go? https://phabricator.wikimedia.org/T122881
22:23:23 <legoktm> according to https://phabricator.wikimedia.org/T131499#2821261 we're all on varnish 4 now
22:23:44 <DanielK_WMDE> we need 4.1 for xkey
22:23:52 <DanielK_WMDE> 4.0 has something similar, but not the same
22:24:00 <DanielK_WMDE> it's called... hashtwo i think
22:24:07 <gwicke> they are async
22:24:14 <bd808> mostly we need bblack to say "start using this feature"
22:24:44 <DanielK_WMDE> gwicke: as long as it's known what resource a rendering is based on when it it served, that is all that is needed.
22:24:45 <bd808> the mod being loaded isn't the same as a blessing that the feature is stable for use at scale
22:24:51 <TimStarling> action item to corner bblack and make him say that?
22:24:57 <DanielK_WMDE> gwicke: asynchronous processes for purging are no longer needed
22:25:07 <bd808> TimStarling: sounds like a good idea
22:25:07 <legoktm> https://wikitech.wikimedia.org/wiki/XKey has some docs
22:25:15 <DanielK_WMDE> bd808: true
22:25:23 <DanielK_WMDE> legoktm: oh, thanks!
22:25:37 <DanielK_WMDE> #link https://wikitech.wikimedia.org/wiki/XKey
22:25:38 <bd808> "We currently do not support setting the same XKey on very large numbers of objects. In practice something on the order of 1-100 objects attached to a given XKey is reasonable."
22:25:52 <bd808> so templates are out
22:26:00 <DanielK_WMDE> for now
22:26:03 <bd808> and lang variants are borderline I would assume
22:26:10 <DanielK_WMDE> but it would be ok for the language use case.
22:26:14 <TimStarling> it sounds like you could go ahead with the software development assuming XKey will be used
22:26:24 <DanielK_WMDE> in practice, we are rarely going to have more than a few languages in the cache.
22:26:31 <DanielK_WMDE> for some languages it could be 200 though
22:26:40 <DanielK_WMDE> #info "We currently do not support setting the same XKey on very large numbers of objects. In practice something on the order of 1-100 objects attached to a given XKey is reasonable."
22:26:49 <gwicke> there is a need for orchestration
22:27:02 <DanielK_WMDE> #info <TimStarling> action item to corner bblack and make him say that?
22:27:13 <DanielK_WMDE> gwicke: for the use case of purging language variants?
22:27:51 <gwicke> purge after updating X
22:28:11 <DanielK_WMDE> ok... so how about the cache fragmentation as such.
22:28:13 <gwicke> most content updates work this way (ex: propagating template edits)
22:28:20 <TimStarling> if xkey needs testing then we need to write the clients for it
22:28:34 <DanielK_WMDE> this proposal basically means putting 20x or maybe 200x as much data into the cache for wikidata.
22:28:37 <TimStarling> so, may as well do this on our side
22:29:24 <DanielK_WMDE> what do you mean by "client" in this context?
22:29:42 <TimStarling> yeah I am being loose with terminology
22:29:53 <TimStarling> for purging an xkey, MW is the client
22:30:02 <DanielK_WMDE> right, ok
22:30:22 <DanielK_WMDE> on thing that bothers me is that xkey doesn't provide a standard http interface fur purging. you get to build your own. there is no standard.
22:30:32 <gwicke_freenode> the matrix <-> irc bridge is slow, so using webchat for now
22:30:36 <DanielK_WMDE> but i guess we can just require it to accept xkey=foo as a url param
22:30:49 <DanielK_WMDE> wb gwicke_freenode
22:31:00 <gwicke_freenode> DanielK_WMDE: I don't think async updates are going anywhere
22:31:13 <gwicke_freenode> we aren't going to re-render millions of pages synchronously
22:31:22 <DanielK_WMDE> gwicke_freenode: my point is i don't think we need them for language variants
22:31:40 <DanielK_WMDE> this isn't about re-rendering, and the template thing was a silly tangent
22:31:49 <TimStarling> HTML cache invalidation via the job queue eventually ends up calling the same functions as synchronous updates
22:32:05 <gwicke> DanielK_WMDE: wait, what would replace async updates?
22:32:18 <gwicke_freenode> heh, matrix has finally caught up
22:32:57 <bd808> DanielK_WMDE: all of our Varnish purges are handled by custom code.
22:33:04 <bd808> so not a scary thing
22:33:07 <DanielK_WMDE> gwicke_freenode: so. Q123 changes. I want to purge all 27 renderings of that from varnish. with xkey, i can do that with one HTTP request instead of 27. And I don't need to know *which* 27.
22:33:12 <DanielK_WMDE> that'S it.
22:33:20 <bd808> right
22:33:22 <DanielK_WMDE> no change to sync/async for now.
22:33:39 <gwicke_freenode> yeah, I was only objecting to your earlier "async is no longer needed" statement
22:34:12 <TimStarling> the patch would be to CdnCacheUpdate
22:34:16 <DanielK_WMDE> gwicke_freenode: that was for the "brave new world" where we put an xkey for every template used... then the work would be left to varnish. but that's a silly tangent, and not going to happen any time soon
22:34:20 <DanielK_WMDE> ok, back to reality
22:34:32 <DanielK_WMDE> #info <TimStarling> the patch would be to CdnCacheUpdate
22:34:37 <gwicke_freenode> even then it wouldn't work
22:34:43 <gwicke_freenode> anyway, back to the topic on hand
22:34:53 <DanielK_WMDE> would it be ok to fragment the web cache for wikidata by x20 [rouch guess]
22:35:12 <DanielK_WMDE> that'S a question for bblack, i suppose?
22:35:22 <TimStarling> yes, we need ops to comment on that
22:35:30 <gwicke_freenode> do you have data on the percentage of anons who would actually select a non-standard language?
22:35:31 <TimStarling> my intuition is "yes"
22:35:42 <DanielK_WMDE> #info ask ops about impact of cache fragementation (x20?)
22:35:43 <gwicke_freenode> or a rough guess?
22:35:47 <DanielK_WMDE> gwicke_freenode: no.
22:35:51 <DanielK_WMDE> no data.
22:36:00 <TimStarling> better to fragment the cache than to not have a cache, right?
22:36:02 <DanielK_WMDE> rough guess... depends on how obvious we are going to make this
22:36:10 <TimStarling> and we have LRU eviction to control cache size
22:36:18 <gwicke_freenode> you goal is to get the localized versions indexed, right?
22:36:19 <DanielK_WMDE> me inclination is that there are relatively few "readers" on wikidata
22:36:30 <SMalyshev> does the client set the xkeys or is it inside varnish config?
22:36:46 <DanielK_WMDE> gwicke_freenode: indexed, and also available to people we want to engage
22:36:52 <TimStarling> SMalyshev:  it is a response header from the backend
22:36:57 <TimStarling> so MW controls it
22:37:12 <SMalyshev> aha. So we'll need the code to create proper xkeys
22:37:36 <DanielK_WMDE> SMalyshev: the page title name will do for this use case. with some prefix, to avoid clashes with other use cases
22:37:40 <TimStarling> yes, and as I was saying before, I think we can go ahead with that code without ops approval
22:37:59 <TimStarling> we can use it for testing, and then get ops approval for final deployment
22:38:20 <DanielK_WMDE> #info <TimStarling> think we can go ahead with [xkey support in CdnCacheUpdate] without ops approval
22:38:27 <SMalyshev> DanielK_WMDE: hmmm not sure. Special:EntityData/Q123 is not the same page title as Q123, but probably needs common xkey
22:38:52 <TimStarling> I think a URL-like namespace would make sense
22:38:53 <DanielK_WMDE> SMalyshev: the xkey for both would be Q123
22:38:55 <DanielK_WMDE> that's the point
22:39:24 <SMalyshev> DanielK_WMDE: but that's not page title, that's only part of it.
22:39:28 <DanielK_WMDE> TimStarling: like wikibase:entity:Q123?
22:39:48 <TimStarling> I mean www.wikidata.org/wiki/Q123
22:39:48 <DanielK_WMDE> SMalyshev: it'S the page title of the actual data. for wikibase, call it the entity id.
22:39:59 <TimStarling> basically use the language-neutral URL as the xkey
22:40:19 <DanielK_WMDE> TimStarling: oh, you want the full URL as the xkey? right - the domain needs to be in there i guess. didn't think of that.
22:40:23 <TimStarling> I don't know if there are implementation reasons to make the keys be really compact
22:40:37 <DanielK_WMDE> #info <TimStarling> basically use the language-neutral URL as the xkey
22:41:04 <DanielK_WMDE> instead of the URL, we might go with the URI, but yea
22:41:08 <DanielK_WMDE> cool
22:41:43 <DanielK_WMDE> so... i have two more bikeshedding questions:
22:42:00 <DanielK_WMDE> what should the path look like? and how do we make wiki-links to a specific language version?
22:42:23 <gwicke_freenode> I still think that paths are problematic
22:42:29 <YairRand> how often would wikilinks to a specific language actually be necessary?
22:42:43 <DanielK_WMDE> YairRand: rare, but useful for discussions and bug reports
22:42:47 <DanielK_WMDE> gwicke_freenode: why?
22:42:53 <DanielK_WMDE> gwicke_freenode: what would you propsoe instead?=
22:43:04 <DanielK_WMDE> parameters? cookies? subdomains? parrots?
22:43:17 <gwicke_freenode> it seems that this mixes content language and UI language
22:43:21 <YairRand> [{{fullurl:title|lang=xx}} link text]
22:43:40 <DanielK_WMDE> gwicke_freenode: well, on wikidata, at least in entity namespaces, they are the same.
22:43:44 <gwicke_freenode> we already have a mechanism that (to users) appears to be a mechanism to select the content language: the domain
22:44:13 <TimStarling> normally the domain selects the wiki, not the language
22:44:39 <DanielK_WMDE> different domain, different community, different rules, different content
22:44:41 <gwicke_freenode> to users, it's the German wiki page about foo vs. the English one
22:44:58 <subbu> DanielK_WMDE, to repeat my earlier comment ... weren't subdomains frowned upon when we discussed the lang. variants proposal? Or, is this only a solution for wikidata?
22:45:01 <DanielK_WMDE> #info gwicke would prefer subdomains instead of pathes to select the language
22:45:08 <gwicke_freenode> I agree that editors might have a different perception, I'm mainly talking about readers
22:45:34 <TimStarling> subdomains were the original proposal for wikidata back in wikidata prehistory
22:45:50 <DanielK_WMDE> gwicke_freenode: i'm open to using subdomains if it doesn't cause too much trouble with cookies and SOP for user scripts and stuff. it should be possible technically. then it'S a product decision.
22:46:00 <DanielK_WMDE> internally, it  should set the uselang request param.
22:46:24 <TimStarling> I think I agreed to it at the time, but I don't think it really helps the user understand what is going on
22:46:31 <gwicke_freenode> how would this affect API responses, for example?
22:46:42 <YairRand> subdomains might cause confusion, especially when the "X language wiki" seems to have loads of content and discussions in language Y and what is it doing here, etc...
22:46:59 <DanielK_WMDE> YairRand: otoh, subdomains would solve the /w/index.php issue nicely
22:47:01 <SMalyshev> there can be more multilang wikis than wikidata...
22:47:16 <gwicke_freenode> if the API responses are expected to be localized as well, then imho the domain really makes more sense
22:47:19 <TimStarling> can use the actual uselang parameter for /w/index.php
22:47:28 <DanielK_WMDE> hm. fr.commons.wikimedia.org?
22:47:42 <DanielK_WMDE> TimStarling: yes, we could.
22:48:00 <DanielK_WMDE> #info <TimStarling> can use the actual uselang parameter for /w/index.php
22:48:06 <gwicke_freenode> that would be messy
22:48:09 <DanielK_WMDE> or we could use /fr/wiki/... and /fr/w/...
22:48:15 <gwicke_freenode> you'd have to encode some custom rules for wikidata
22:48:18 <YairRand> are subdomains are piling up? fr.m.meta.wikimedia.org...
22:48:21 <DanielK_WMDE> or /lang/fr/wiki/...
22:48:33 <DanielK_WMDE> YairRand: heh, indeed!
22:48:52 <gwicke_freenode> /api/lang/fr/rest_v1/?
22:49:07 <DanielK_WMDE> ok for an api
22:49:13 <DanielK_WMDE> i don't really want to see that in my browser
22:49:17 <DanielK_WMDE> or type it in
22:49:59 <DanielK_WMDE> ok, i guess we'll have to discuss pathes vs subdomains another time. it doesn't re4ally tough the other issues
22:50:05 <DanielK_WMDE> actually...
22:50:23 <DanielK_WMDE> one thing this needs to make the language "stick" is to mess with $wgArticlePath
22:50:40 * cscott pokes his head in
22:50:45 <DanielK_WMDE> that will need som func refactoring, to make it work with both proper "DI" style code and stuff that relies on global state
22:50:52 <DanielK_WMDE> ...and with IContext...
22:51:02 <TimStarling> legoktm has been refactoring link generation already
22:51:14 <DanielK_WMDE> yes, I love it!
22:51:26 <DanielK_WMDE> that will help a lot
22:51:41 <TimStarling> probably better to work on top of that than to hack $wgArticlePath
22:51:45 <cscott> DanielK_WMDE, MaxSem: let's definitely sit down at dev summit in a month and a half to discuss ui language & other language stuff.
22:51:46 <DanielK_WMDE> any, I think it will be simple enough to make this work gor 95% of links.
22:52:05 <DanielK_WMDE> cscott: yes, let's!
22:52:05 <TimStarling> one other note about implementation details
22:52:24 <TimStarling> you said in the task that the language-neutral URL should be rewritten to a special page
22:52:47 <DanielK_WMDE> yes, eventually. probably not initially
22:53:03 <TimStarling> I don't think we should have intelligence in the web server, I think the web server should just send everything to index.php
22:53:11 <TimStarling> then use PathRouter, which is hookable
22:53:32 <TimStarling> here's how variants work:
22:53:40 <TimStarling> if ( $wgVariantArticlePath ) {
22:53:40 <TimStarling> $router->add( $wgVariantArticlePath,
22:53:40 <TimStarling> [ 'variant' => '$2' ],
22:53:41 <TimStarling> [ '$2' => $wgContLang->getVariants() ]
22:53:41 <TimStarling> );
22:53:41 <TimStarling> }
22:53:46 <TimStarling> simple, right?
22:53:56 <TimStarling> easily extended to do what you want to do
22:54:49 <DanielK_WMDE> not quite sure i guet what that does, but it tells me there is a nice hookable place to deal with patches
22:54:58 <TimStarling> yeah, the hook is WebRequestPathInfoRouter
22:54:59 <DanielK_WMDE> i'm fine with doing it in php
22:55:15 <DanielK_WMDE> more control to me, less reason to bother ops ;)
22:55:25 <gwicke_freenode> #info Gabriel would like to see some details on how language selection would affect API responses (both PHP and REST)
22:55:44 <DanielK_WMDE> #info <TimStarling> [use PathRouter, which is hookable; the hook is WebRequestPathInfoRouter]
22:56:16 <DanielK_WMDE> gwicke_freenode: it just sets uselang. how does uselanfg affect RESTbase responses?
22:56:25 <gwicke_freenode> it does not at all
22:56:29 <DanielK_WMDE> Thanks for the pointer, Tim!
22:56:42 <DanielK_WMDE> well then, that's how it will be.
22:57:03 <DanielK_WMDE> gwicke_freenode: does restbase support different page renderings based on user language?
22:57:06 <gwicke_freenode> that wouldn't work if your frontend widget wants localized content
22:57:50 <DanielK_WMDE> well, wikibase widgets don't use restbase
22:58:01 <gwicke_freenode> we currently support one content language per domain
22:58:10 <DanielK_WMDE> and the only other pages affected would be pages that work like image description pages
22:58:37 <DanielK_WMDE> so restbase doesn't work on multilingual wikis. that's not going to change with this proposal.
22:58:58 <gwicke_freenode> my point is that we should have a coherent plan
22:59:06 <gwicke_freenode> rather than treating it as an afterthought
22:59:26 <DanielK_WMDE> i agree, but i'm not quite sure i understand your question
22:59:30 <TimStarling> any other things for the notes before the meeting ends?
22:59:37 <DanielK_WMDE> to make restbase work with multilingual wikis, it needs to ssupport multilingual wikis
22:59:44 <DanielK_WMDE> that has nothing to do with per-ölabguage urls
22:59:52 <DanielK_WMDE> but i'm happy to discuss the topic some other time
23:00:14 <gwicke_freenode> well, for RB it would be quite natural to model this as different domains
23:00:28 <gwicke_freenode> hence my preference for using those
23:00:30 <DanielK_WMDE> gwicke_freenode: do you want RB to support commons?
23:00:38 <TimStarling> gwicke made a note that he would like to see more info about API schemes
23:00:39 <gwicke_freenode> it already does
23:00:52 <DanielK_WMDE> ok, thank let's talk about how that works
23:00:54 <TimStarling> so fine, let's move on with other business considering there is -1 minute remaining
23:01:21 <DanielK_WMDE> thanks for chairing, TimStarling!
23:01:32 <DanielK_WMDE> and thank you everyone for the fruitful discussion!
23:01:40 <DanielK_WMDE> I new feel we can move forward with this
23:01:43 <DanielK_WMDE> *now
23:01:55 <TimStarling> did we have a topic for next week in the end?
23:02:03 <DanielK_WMDE> Deprecation policy
23:02:18 <DanielK_WMDE> https://phabricator.wikimedia.org/T146965
23:02:23 <DanielK_WMDE> up next week --^
23:02:23 <subbu> i guess we didn't get to discussing https://phabricator.wikimedia.org/T122942 today.
23:02:36 <TimStarling> ok, be there or be square
23:02:41 <TimStarling> #endmeeting