21:00:24 #startmeeting RFC meeting 21:00:24 Meeting started Wed Apr 27 21:00:24 2016 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:24 The meeting name has been set to 'rfc_meeting' 21:00:35 ah, i was wondering if I was in the right place 21:00:45 #topic RFC: Support language variants in the REST API | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ 21:01:21 hi 21:01:32 hello 21:01:49 o/ 21:01:49 Hello 21:02:05 so, we have been thinking about the best way of exposing different languages and their variants in the REST API 21:02:07 Congratulations, Rob re Architecture Committee!!! 21:03:10 while the focus is on the REST API (which brings some requirements and constraints like caching), it is closely related to the bigger question of how we represent different language selections in URLs / requests 21:03:35 phab meeting: https://phabricator.wikimedia.org/E168 rfc task: T122942 21:03:35 T122942: RFC: Support language variants in the REST API - https://phabricator.wikimedia.org/T122942 21:03:49 DanielK_WMDE__ has started a related non-API discussion at https://phabricator.wikimedia.org/T114662 21:04:42 in that thread, one of the key questions that emerged was about the desired granularity of language selection 21:04:52 i think we can come up with a reasonable consensus for the REST API. I don't know about settling any broader questions. 21:05:09 purodha summarizes this question well in https://phabricator.wikimedia.org/T114662#2005122 21:05:14 can we have a link to the current REST API documentation? 21:05:33 to clarify, this rfc settles the URL interface for specifying when you're pulling a particular variant, which then opens the further separate question of how to implement the conversion in parsoid etc. correct? 21:05:35 https://en.wikipedia.org/api/rest_v1/?doc 21:05:54 #link https://en.wikipedia.org/api/rest_v1/?doc current REST API documentation 21:05:56 this RFC is about selecting content languages in the REST API 21:06:50 T114662 is about URLs for mediawiki articles; I'm not sure that's strictly related. that is, we can pick some solution for the REST API w/o changing how we do article URLs, or vice-versa. 21:06:50 T114662: RFC: Per-language URLs for multilingual wiki pages - https://phabricator.wikimedia.org/T114662 21:07:04 I made an attempt to enumerate the options under consideration in T122942 . cscott tried to narrow it down 21:07:04 T122942: RFC: Support language variants in the REST API - https://phabricator.wikimedia.org/T122942 21:07:12 another aspect related to the granularity is whether we should expose whether something is a variant / auto-translated vs. a separate project 21:07:57 is that really a question? 21:08:01 I personally think that we should have a consistent plan for selecting languages, and an idea for the granularity we are shooting for 21:08:35 i think projects and variants are distinct. I don't see any reason to conflate them, or to obscure which project is responsible for a given bit of content. 21:08:42 to clarify further: we already have domains for projects, correct? 21:09:04 brion: arguably too many, if I understand ops correctly. 21:09:08 :) 21:09:11 yes, we have domains for projects, but some of the projects are actually variants 21:09:14 I agree with cscott 21:09:15 like zh-yue 21:09:22 just wondering how one would add a second layer of subdomains without ops killing us 21:09:23 gwicke: that is not correct. 21:09:35 zh-yue is a variant of zh 21:09:43 but some projects have multiple languages? 21:09:43 in the language sense 21:09:44 yeah yeah 21:09:49 and italian is a variant of latin 21:09:51 cantonese is a distinct language. the cantonese wiki is a distinct project. 21:10:17 importantly, the decisions about which languages (or variants) get their own projects is not a technical matter, it's an issue decided by the community. 21:10:26 but it's not really about linguistics, like cscott says, we have a very clear user-facing concept of a wiki and there's no sense conflating it with automatic translation 21:10:50 trying to do so would potentially cause conflicts 21:10:55 secondarily we have commons, meta, mediawiki.org, etc which may carry pages of multiple different languages, have templates that render differently in different lanugages etc 21:11:05 it would be quite possible to have a zh-yue variant of zh, and simultaneously a zh-yue wiki 21:11:20 i would tend towards a solution that treats language variants and alternate language renderings of the same page on the same project similarly 21:11:31 brion: yes, that's more what T114662 is discussing. i'm not convinced it is best to discuss that at the same time as T112942. 21:11:31 T112942: [Regression] PHP version check broken in load.php and api.php - https://phabricator.wikimedia.org/T112942 21:11:31 T114662: RFC: Per-language URLs for multilingual wiki pages - https://phabricator.wikimedia.org/T114662 21:11:35 cscott brought up the prospect of conflicts, but I think it's not clear to me that we actually want to have many different ways of accessing content in a given language variant 21:11:36 while treating "project id" as totally separate 21:11:47 cscott: how would they differ? 21:12:23 I'd say we should treat zh-yue variant on zh wiki the same way as we treat zh language on commons - one way of many of representing same wiki's data 21:12:31 brion: the commons issue introduces the notion of "interface language" as concept distinct from "source language" or "rendered variant". 21:13:07 brion: +1 21:13:08 the language-neutral parts of commons or metawiki is presented in an "interface language". the actual content has a "source language" which may (or may not) be rendered into a particular variant. 21:13:19 hmm 21:13:31 brion: confating project ids with language ids causes no end of pain for wikidata & co. 21:13:34 templates are part of the "interface", and so separating "content" from "interface" is not always straightforward. 21:13:35 it's a *bad* idea 21:13:45 it's a very interesting discussion, i just don't think it's strictly related to the REST API discussion. 21:13:47 cscott: it's not only interface, as GUI - the data itself can have different language representations 21:13:58 are template localizations selected against $wgUserLang or something else? 21:13:59 SMalyshev: right. wikidata has that issue as well. 21:14:15 you are discussing the granularity bit 21:14:18 i think it's related insofar as if they're not the same thing they're almost identical and need to be treated similarly 21:14:24 some wikidata api meodules allow language filters to be specified 21:14:25 brion: i don't think that was quite decided. we discussed that at the last dev summit, w/o reaching consensus. 21:14:47 but i don't see a good way to generalize this. the semantics and specifics really depend on the module 21:14:51 so localized templates today are done based on user language, so far as i know, as there is no other mechanism yet 21:15:11 in some cases, you have a target language, in others, you specify a fallback chain. in some cases, the languages act as a filter, in others they trigger translitteration 21:15:21 T114640 is also related to the interface language question. 21:15:21 T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis - https://phabricator.wikimedia.org/T114640 21:15:50 and DanielK_WMDE has been the lead on those issues (just establishing context for others new to the discussion) 21:15:50 cscott: btw, the api also has an interface message, for error messages. 21:15:56 generally, the REST API is exposing content in a given language, and optimizes for cacheability 21:15:58 so it sounds like we have two distinct language settings: content language and UI language, each of which may have a variant 21:16:11 *and* the namespace of variants overlaps with the namespace of languages potentially 21:16:19 can we verify that last point as true/false? 21:16:28 brion: strictly speaking, you also have various fallbacks based on logged-in user preferences as well. 21:16:41 brion: consider an en-gb variant on enwiki and simplewiki. 21:16:48 yes, variants can be either auto-translated, or separate projects as with zh-yue 21:17:11 cscott: right, so en-gb may be either a standalone language or a variant of en 21:17:12 we *could* rename things as necessary to ensure projects and variants never overlap, but that's never been necessary before. 21:17:20 brion, ah interesting reg. content and ui language and each of them having variants ... i hadn't realized that additional complexity. so, ui language only affects ui messages and content language affects content represented in wikitext? 21:17:23 is there anyone other than gwicke who supports option #1? 21:17:33 everyone else seems to have spoken against it 21:18:03 ui language affects any wikitext content that varies based on {{#userlang}} (is that the right function name?) or whatever equivalent lua magic, i suppose 21:18:24 subbu: it should be said that "ui language" is partially a fiction at this point. that is, it exists in our minds but doesn't have a clear expression in mediawiki code... yet. 21:18:24 I would like to propose that we reject option #1 and move on to discussing the other options 21:18:29 TimStarling, I think you are a bit premature with your question 21:18:52 T114640 and T114662 are attempts to codify "ui language" in the codebase (among other things) 21:18:53 T114662: RFC: Per-language URLs for multilingual wiki pages - https://phabricator.wikimedia.org/T114662 21:18:53 T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis - https://phabricator.wikimedia.org/T114640 21:18:56 #info question discussed "do the namespace of variants overlap with the namespace of languages?" 21:18:58 i would reject option 1 (adding domains) 21:19:31 domains should map directly to high-level projects, which are separate and distinct places you can interact with 21:19:37 which may, or may not, have anything to do with languages 21:19:42 brion: +1 21:19:54 eg meta and commons are not languages :) 21:20:03 those are different levels of the domain 21:20:03 #info TimStarling and brion propose rejecting the "adding domains" option 21:20:33 wikisource.org is one site (multilingual), de.wikisource.org is another (which happens to be centered on one content language) 21:20:40 I attempted to clarify what the 4 options under consideration are here: https://phabricator.wikimedia.org/T122942#2244988 21:21:34 can i suggest renarrowing the discussion to the REST APIs? Or do we think that it's worthwhile to discuss DanielK_WMDE's more general questions about article URL paths? (T114*) 21:21:34 T114: The order of tasks in Phabricator Boards doesn't always save - https://phabricator.wikimedia.org/T114 21:21:37 I agree, I think domain should be project,. for some projects it defines language, but for others it doens't so putting it there will only confuse matters 21:21:49 ah, i was trying to shut up stashbot by using the wildcard. didn't work... 21:22:13 ok, so can we discuss option #2 versus option #3? 21:22:31 cscott: we should at least answer the question why the two should be different. 21:22:38 in https://phabricator.wikimedia.org/T122942#2144512 .. bianjiang proposes http headers in case that is a candidate worth considering ... 21:22:38 cscott: article url paths are distinct from rest api urls, but language selection for on-wiki translations seems roughly identical to this problem in scope and rules and should probably be treated together 21:23:00 or whether they should follow the same pattern. having two different solutions to the same probloem isn't nice. if it is the same problem. 21:23:03 that's the question 21:23:32 DanielK_WMDE: the API paths in https://en.wikipedia.org/api/rest_v1/?doc don't look (to me) anything like article paths. 21:23:35 fwiw, we are using domains heavily internally in the REST API, and will very likely continue to use them for variants as well 21:23:51 the question is whether this should be hidden from view (only internal), or exposed 21:24:01 domains specify the project aka database 21:24:10 I don't think you should use domains internally for variants 21:24:16 you could always fix that 21:24:24 cscott: no, but if we decide to use subdomains for content variants, we probably should do the same for the api, no? 21:24:34 and whether we really want both https://zh.wikipedia.org/zh-yue/ * and https://zh-yue.wikipedia.org/zh-yue/* 21:24:53 * DanielK_WMDE does not think we should have variants in the subdomains 21:25:05 TimStarling, domains are unique ids for projects 21:25:06 DanielK_WMDE: not sure. the article paths have all sorts of human-friendly features, like if you're logged in and hit the generic /wiki/{title} path you get content according to your user preferences. 21:25:36 DanielK_WMDE: that should probably be a redirect or something eventually to preserve cacheability. but the point is that article URLs are meant for people to consume. the REST URLs are not. 21:25:39 gwicke: to me, they mean different things: the first one is denotes a variant transformation, the second one separate content. 21:26:05 option 2 would be something like /en-gb/page/html/Australia , right? 21:26:08 gwicke: i don't think you can decide "whether we really want both https://zh.wikipedia.org/zh-yue/ * and https://zh-yue.wikipedia.org/zh-yue/*". that's a matter for the communities of those wikis to decide. 21:26:19 cscott: true, but why not follow the same patterns, and use the same mechanims? 21:26:22 gwicke: if they exist, they exist 21:26:28 cscott, it is also a product question for wmf 21:26:32 cscott: note that API responses *are* specific to the user language 21:26:42 and option 3 something like /page/variant/en-gb/html/Australia ? 21:26:43 gwicke: it is not a question that can be settled in an RFC meeting. 21:26:57 DanielK_WMDE: no, api responses are based on the wiki's content language 21:27:08 i.e. with option 3 you avoid mixing language codes with API endpoint identifiers 21:27:20 so you can have an Apiaka language or whatever 21:27:26 which seems elegant to me 21:27:34 gwicke: they supprt uselang. and i think it defaults to the user's ui language - but i could be wrong 21:27:45 gwicke: i think it's only used for error messages, but still 21:27:49 DanielK_WMDE, the REST API does not support uselang 21:27:50 i think your option 3 syntax is fine. 21:28:10 TimStarling, so the proposal is /zh-yue/api/rest_v1/...? 21:28:24 gwicke: so, no localized error messages? 21:28:25 or /api/rest_v1/variant/zh-yue/...? 21:28:30 DanielK_WMDE, nope 21:28:38 shame ;) 21:28:40 * gwicke shudders 21:28:40 the second one 21:28:53 /api/rest_v1/page/variant/en-gb for option 3. i'm not sure what the full path for option 2 is. 21:28:54 /variant introduces the language code 21:29:02 #info question discussed: should we use the "option 3" syntax proposed in the meeting? 21:29:15 i don't really like the "variant" but. in my mind, you specify the desired target language 21:29:31 if the desired target language is a variant of the actual content language, we can transform the content 21:29:39 this would be solution only for variants, not multilingual content, right? 21:29:41 but like cscott says, and like my example just now, I'm not saying it should be a prefix for the whole REST API like /api/rest_v1/variant/zh-yue 21:29:42 if it's something else, well, then we can't transform 21:29:52 instead of "variant" maybe "langconvert"? LanguageConverter is the name of the code which is doing the transformation. 21:29:56 I think it could be under /page 21:30:08 ok, so on zh.wikipedia.org i can confirm I can both set my ui language *and* pick a content variant 21:30:08 how about just "language" instead of "variant"? 21:30:22 if the original content is multilingual or language neutral, all kinds of target languages could be supported 21:30:26 think commons or wikidata 21:30:34 ui language is a separate concept, and largely irrelevant for the REST API 21:30:46 generally, the REST API is aimed at client-side UI composition 21:30:52 To take DanielK_WMDE's side for a moment -- what if you want to specify user interface language, not just a variant conversion. 21:30:58 gwicke: rest api can serve HTML of rendered pages correct? if so, it must known UI language to pass it thorugh for rendering of templates 21:31:02 which means that clients can use whatever UI language they like, but consume data in another language 21:31:07 or else we need an alternate way to handle translatable templates 21:31:12 ideally a REST API would have HATEOAS-style hyperlinks, right? 21:31:19 unfortunately, the REST API *does* have UI stuff, in so far as there are templates on commons/etc which are part of the UX, not part of the "content" per se. 21:31:19 SMalyshev: i really want variants and multilang content to work the same. translated content is different. 21:31:37 so you should be able to get a listing of available variants with /variant/ 21:31:46 cscott: the target language isn't hte "ui" language. is the desired language for the content. 21:31:48 DanielK_WMDE: me too, but the proposed option 3 wouldn't do that, iiuc 21:32:15 DanielK_WMDE/SMalyshev: right now I think we're agreed that translated content is handled as an article suffix, right? Foo is the article, Foo/en-gb is the translation. 21:32:25 TimStarling: if we have per-page content rev, need to make sure we can ask for list of variants per-page right? 21:32:40 cscott, that is already taken, so would break existing apis 21:32:51 cscott: it's not translation. I.e. commons description can be in English and German, they are not translations 21:33:06 brion: yes, I suppose so 21:33:17 cscott: if you had API that gets commons image data, including description, wouldn't you want to specify which language description you want? 21:33:26 DanielK_WMDE: you can be viewing zhwiki in the simplified variant, yet have your UX language set to english or german. the templates in File:* (in theory) should respect your UX language. as far as I understand it. 21:33:47 I am getting confused by this discussion .. I thought the proposal that seemed that might work was "/page/variant/en-gb/html/Australia". Am I mistaken? 21:33:59 cscott, UI language is mostly irrelevant 21:34:03 but having subpaths of articles is a bit awkward when they can contain slashes in the titles 21:34:25 TimStarling, as you know, slashes are encoded 21:34:26 you would have to encode them as %2F 21:34:33 subbu: i think the discussion on the REST api is pretty solid, Tim's suggestion seems good. but DanielK_WMDE wants to use a consistent mechanism for article URLs as well, and that's a harder problem. 21:34:55 but, as I said, the suffix path is already in use (for revision selection) 21:35:14 cscott: yes, translated content uses suffixes. independent content uses subdomains. but the "target language" for multilang content should be as the "variant" for transformable trext 21:35:22 i'm sympathetic to DanielK_WMDE's desire, of course. i think it's an interesting question. but it does make the structure of this meeting somewhat challenging. ;) 21:35:33 gwicke: Foo%2Fen-gb 21:35:37 ok, so if you have a /variant suffix then that can achieve brion's goal of listing variants on a per-page basis 21:36:11 the only thing I can see working so far is something like /api/rest_v1/page/variant/{something}/... 21:36:13 i'm not a big fan of overloading suffixes, but at least it's 100% distinguishable from revision numbers 21:36:25 /page/Australia/variant/ could give a list of variants 21:36:27 DanielK_WMDE: so in my example for zhwiki, how do you solve that problem? you can't localize text in a variant if your UX language is different? 21:36:43 gwicke: i'm good with that if we replace "variant" with "language" 21:36:51 /page/Australia/variant/en-gb/html could give the HTML in the en-gb variant 21:37:11 cscott, DanielK_WMDE: i tend to agree it'd be ideal to merge variant and language but i may be wildly incorrect ;) 21:37:14 ../page/html/Australia/12345 is already that revision of Australia 21:37:16 *UI language 21:37:34 and ../page/html/Australia/12345/ lists renders of that revision 21:37:35 gwicke: /\d+/ does not match "variant" 21:37:40 brion: i'm just not sure how to actually render a zhwiki page if you set "en-gb" as your language. 21:37:40 cscott: not if the target language is defined to be the UI language. this is the case for wikidata. for zhwiki, the target language is taken from the url path, so no problem, right? 21:37:49 it's very easy to distinguish those, though you may not wish to ;) 21:37:50 gwicke: that's why you always need a keyword in the path, for extensibility 21:37:53 brion, that's.. ewww... 21:38:02 gwicke: yeah :) 21:38:11 there's a conflict between positional parameters and named parameters here 21:38:13 cscott: for commons and wikidata, the target language should probably always be the user's ui language. but for zhwiki and co, perhaps it shouldn't. not sure 21:38:24 you can always add positional parameters but urls get ugly when there's a million empty ones 21:38:35 and named parameters in url path part pairs feel weird 21:38:48 DanielK_WMDE: unfortunately, if you don't run languageconverter for *some* specific variant, you get text which is a mishmash of character sets which basically no one can read. 21:39:04 it's not strictly named parameters, it's still hierarchical, there's a defined order 21:39:07 cscott: sure, in that case run to some reasonable default .... oh shit politics ;) 21:39:16 DanielK_WMDE: hence my feeling that it's best to separate the "pick a variant" part from the "ux language" part. 21:39:26 brion: yeah. 21:39:42 brion: variant and target language are handled in the same place internally: Content::getParserOutput gets Content that is in language X (or multilang) and is asked for output in language Y. if Y is a variant of X, a transformation can be applied. 21:39:42 wow this is a way more controversial topic than i expected 21:39:55 i mean, i could be convinced that we can just pick some behavior arbitrarily and this is a corner case and it won't matter in the end. i just haven't quite been convinced of that yet. 21:40:13 brion, as far as i know this has always been a controversial topic. 21:40:17 cscott: my point is that it's "pick a target language", not "pick a variant". the target language may or may not be tied to the ui language. 21:40:32 there's only two hard problems in computer science.. 21:40:38 for user language you can have /variant/en-gb/userlang/en-au 21:40:38 brion, sorry misinterpreted .. you said: "way more" .. 21:40:44 DanielK_WMDE: i tend to like that model, but agree that we may not know what importance of corner cases will be 21:40:45 DanielK_WMDE: yes, but isn't the point of the T114* bugs to try to separate those languages internally? 21:40:45 T114: The order of tasks in Phabricator Boards doesn't always save - https://phabricator.wikimedia.org/T114 21:40:54 cscott: when viewing commons content, you want to specify the output language. that's not a variant. and it might be different from your ui language (though i find that a bit pointless) 21:40:58 but it's hierarchical, it's not key-value, you can't have /userlang/en-au/variant/en-gb, it's not in the schema 21:41:03 (subbu: url structure for apis is usually boring stuff) 21:41:14 * subbu nods 21:41:34 the actual details of the converter yeah :DD 21:41:52 what is the use case for this userlang stuff? 21:41:53 cscott: the point is to internally have a clear notion of the (stored) content language, the desired target language, and the effective output language. 21:42:00 ...and the UI language 21:42:15 gwicke: labels for commons and wikidata metadata, like field labels, etc. 21:42:20 remember that this is an API exposing data 21:42:22 not UX 21:42:25 four languages instead of two-plus-odd-bits 21:42:33 https://phabricator.wikimedia.org/T114662 describes some of the use cases 21:43:00 gwicke: i'm not sure, i'm talking about a target language. i don't see how the user language playes into this., 21:43:50 in MW terms, what we are interested here is the *content language* 21:43:54 cscott: in wikidata, we would tie the target language to the UI language. but the api shouldn't know or care, and it could be different on other projects 21:44:00 the main reason to specify both would be to say 'i'm viewing in language X but need to look at content for language Y'... but i think in a world where UI is more separate from content things may change a bit in the semantics 21:44:28 eg is it ok for the template that links to translations to *not* be translated in french when i look at https://www.mediawiki.org/wiki/Manual:Extension_registration?uselang=fr ? 21:44:52 currently https://www.mediawiki.org/wiki/Manual:Extension_registration english and https://www.mediawiki.org/wiki/Manual:Extension_registration/fr french pages are distinct, but the template at the top localizes to whatever my uselang is 21:44:53 gwicke: again, the problem is that some of our "content" contains "interface" elements. it sucks, but that's how it is. 21:45:06 is the template content? or is it meta-ui? 21:45:16 templates are content as far as I am concerned 21:45:21 even if we remove crap like labeling the "Table of contents" or "edit links" we still have those 21:45:22 brion: yes, that's the question of when and how the target language should be tied to the ui language. it's an interresting one, but not one we need to answere in the context of todays rfc, i think 21:45:46 DanielK_WMDE: my concern is just that if we add "/variant" on the end do we have to scramble next week to add "/uselang" ? 21:45:55 DanielK_WMDE: right, it doesn't need to be answered, and really a lot of your comments have been a distraction 21:46:01 hehe 21:46:04 The {{int}} template/parser function is also interesting. 21:46:16 if we think it's ok to treat those at different times, then i withdraw much of my conversation for now :) 21:46:18 what we need is to answer gwicke's actual implementation problem in a way that is reasonably forwards-compatible 21:46:39 and we can discuss all the things we can do with that forwards-compatibility some other day 21:46:39 i still like /page/variant/{foo} 21:46:56 TimStarling: i'm sorry to hear that. all i want is really to not call it a variant, but a target language, and think in these terms. no further derailment intended 21:47:08 cscott, I think so far that's the only proposal that would not break existing apis 21:47:09 sorry, /page/langconvert/{foo} 21:47:22 that will be specific to "invoke the language converter as apost processor" 21:47:27 (apart from domains, which everybody seems to dislike) 21:47:32 does langconvert return html same as /page/html/{foo}? 21:47:33 we can figure out some cool way to unify these later, maybe. 21:48:00 brion: yeah, sorry. it should be like tim wrote it. /page/langconvert/en-gb/html/... 21:48:07 brion, it would be a mirror of the page hierarchy 21:48:21 hmm, that sounds ok for that 21:48:23 or /page/langconvert/en-gb/page/html/... even. 21:48:24 so /api/rest_v1/page/variant/zh-yue/html/Foo 21:48:36 but if we add a second option, how do we reconcile the two tree prefixes? 21:49:19 a second option for language selection? 21:49:28 or is it safe to in future extend semantics of /page/variant/zh-yue/html/Foo to support /page/variant/fr/html/Foo ? 21:49:29 brion: best case: I take everything after /langconvert/{code} and pass it back into REST, and do the language conversion on the output. 21:49:31 are you thinking about regions? 21:49:35 gwicke: for target language that isn't a variant 21:49:52 so if /page/coolness/ is ever a thing, then /page/langconvert/en-gb/coolness/... will Just Work. 21:49:55 does it matter whether it's a variant? 21:50:03 * DanielK_WMDE is good with /page/langconvert/{foo} 21:50:08 .. /langconvert/:/ if ever that ui_lang needs to be added? otherwise /langconvert// works? 21:50:33 .. /page/langconvert/... i mean 21:50:35 subbu: ui_lang is actually part of template expansion, not language conversion. sadly. 21:50:36 gwicke: what do you mean by "language selection" exactly? 21:50:42 zh.wikipedia.org/api/rest_v1/page/lang/en-gb/html/Foo 21:50:47 ie, it influences how the {{int 21:50:53 }} template is expanded. 21:51:04 oye. 21:51:05 DanielK_WMDE, select the content language 21:51:19 langconvert feels like a very specialized filter, like mobile-text 21:51:33 so it would be /page/langconvert/en-gb/ui_lang/de/html/ArticleTitle, in one version of the future. 21:51:39 gwicke: does that select where the content is loaded from? i.e. the project? 21:51:40 one thing I'm concerned about with schemes like this is what it does to the API documentation 21:51:57 it will basically duplicate the bulk of the API docs in a second hierarchy 21:52:13 I would be happy to approve a range of possible path-based schemes at this point 21:52:22 gwicke: some of the api endpoints shouldn't be necessary for /langconvert/ 21:52:26 with the exact scheme at the discretion of the implementor 21:52:34 ie, listing revisions. that can be done on the main /page endpoint. 21:53:04 cscott: revision comments need to be run through the converter don't they? 21:53:07 yeah, which makes it even more subtle 21:53:16 i'd like to suggest that we discuss DanielK_WMDE's general language questions in a follow-up meeting, not too long from now. 21:53:33 brion: those come from the action api, not from rest. 21:53:42 it sounds like there's a tradeoff between cachable URL schemes and ease of documentation with tools like Swagger 21:53:46 ugh 21:53:56 brion: and parsoid doesn't really implement "revision comment" parsing, which differs from normal parsing in a bunch of obscure and painful ways. 21:53:59 I don't want to bikeshed, I just want it to be done 21:54:20 cscott: sounds good - i'd like to suggest that we discuss DanielK_WMDE's general language questions 21:54:31 TimStarling, the reason we wrote this RFC is that we want to do this consistently with the general strategy of language selection 21:54:34 so lets not rush it 21:54:59 * subbu is happy with path-based schemes 21:55:27 I'm happy to help someone (cscott?) to come up with a concise list of open questions for this RFC 21:55:34 well, i think that variant conversion is currently "next" on my plate, after balanced templates. but it will still be a while before any patch i write is actually ready to be deployed into production. 21:55:34 it wouldn't make sense to have several different path-based ways of selecting language variants, for example 21:56:02 robla: i think we've got a reasonable consensus on an interim solution, but concern over the more general questions of DanielK_WMDE is preventing us from finalizing anything. 21:56:07 (which i actually agree with) 21:56:29 so i think the way to make further progress here is to actually grapple with the more general url scheme question, then return here and see if the solution to that problem bears on this one. 21:57:01 what we are looking for is basically option 2 21:57:08 i don't want to derail or stonewall this or related rfcs. 21:57:18 a uniform path-based way of selecting language variants 21:57:21 are we otherwise happy with the notion of zh.wikipedia.org/api/rest_v1/page/lang/zh-hant/html/Foo with the open question of whether zh-hant can be replaced with en/fr/etc in a way that will be consistent? 21:57:29 well, we're not holding anything up until i've actually got a patch in hand. which i don't yet. 21:57:43 i just want to make sure we have a good concept of how we handle languages in general 21:57:54 or do we need to ponder more before committing to that model? 21:57:57 brion, i think DanielK_WMDE preferred /langconvert/ over /lang/ i think unless i misunderstood it. 21:58:12 ist egal zu mir, as the germans say :D 21:58:15 I think /page/lang/ would be the most neutral one without overfocusing the semantics 21:58:15 i'll take langconvert 21:58:23 the issue with /langconvert/ et al is that it's a one-off solution for the REST API 21:58:24 subbu, brion: i'm good with /lang/. "convert" is an implementation detail. 21:58:30 though lang is happy yeah 21:58:41 * brion "take it to #wikimedia-bikeshed!" ;) 21:58:42 rather than someting that will work for articles as well 21:58:50 subbu: i just don't want /variant/, because i think it's too narrow 21:58:50 DanielK_WMDE: cscott : is there an action item for DanielK_WMDE to write up a generalized RFC for URL policy? 21:59:06 DanielK_WMDE, ok .. thanks for clarifying. 21:59:16 gwicke: yeah, but a one off solution might be enough for now. it might turn out that the more general /page/html/lang/foo/balh solution internally dispatches to /page/langconvert/ to do the actual language conversion part. 21:59:26 TimStarling: what say you? we're coming up on time 21:59:36 yes, fine 21:59:38 robla: i could wrinte an rfc that is just about terms and concepts, not about code at all. 21:59:41 so maybe /page/langconvert doesn't actually have to be a part of the public api in the end. but it's a useful narrow solution to the immeditate implementation issue. 21:59:44 cscott, that doesn't make sense 21:59:53 the url you propose is already in use 22:00:19 i don't like /lang/ specifically because it's more general than i'm happy with right now. i'm not convinced that language converter and the other languages involved can be unified in the end. 22:00:25 agh did i mean /api/rest_v1/lang/zh-hant/page/html/Foo ? 22:00:32 maybe they can be. but at the moment i'd like a narrow solution to a specific problem. 22:00:42 time's up now 22:01:02 brion, it might make sense to shift it up one or more levels, yes 22:01:23 [it may be worth considering it a filter like /page/mobile-text/{title} that might go away some day in favor of a more general solution] 22:01:25 also in the running: /zh-yue/api/rest_v1/... 22:01:32 and /zh-yue/wiki/... 22:01:33 who is going to update the RFC page? gwicke or cscott? 22:01:44 May 4 meeting: https://phabricator.wikimedia.org/E169 about PSR-6 22:01:49 i think it's gwicke's RFC 22:02:04 we should perhaps update DanielK_WMDE's RFC as well 22:02:18 brion: "[it may be worth considering it"... yes, that's what i'm suggesting. 22:02:24 gwicke: in what way? 22:02:26 #action gwicke to update T122942 to summarise the options discussed here and remove the rejected option 22:02:27 T122942: RFC: Support language variants in the REST API - https://phabricator.wikimedia.org/T122942 22:02:37 cscott: +1 22:03:25 #action DanielK_WMDE to write an RFC discussing the philosophical nature of language 22:03:37 lol 22:03:44 TimStarling: hehe ;) 22:03:49 :) +1 22:03:53 haha 22:03:58 #endmeeting