[05:09:16] \close [20:07:10] in about an hour, cscott will be asking for discussion on Square bounding boxes and Scoped language converter RfCs here in #wikimedia-office. [20:13:20] Which is to say [[Requests for comment/Square bounding boxes]], not [[Square (company)]] bounding boxes [20:13:38] actually, [[Square bounding]] boxes [20:14:12] cscott: btw, I'd love to have a ready-to-copy-and-paste summation of what you'd like to get out of today's discussion for each of those RfCs [20:14:18] dent-length is fine [20:15:13] sumanah: I guess dent-length is "unlimited" now though :) [20:16:04] ah, here I was thinking I would avoid FLOSS nitpicking from marktraceur by using "dent", but instead I got a well-actually nitpick instead. [20:16:05] Scoped language converter: (a) confirm consensus on replacing the existing template-based system with a "glossary" system. (b) discuss how glossaries should interact with templates (page inclusions) [20:16:44] * sumanah remembers that colleagues haven't signed up for the Hacker School social rules [20:16:57] marktraceur: after wikimania, I insist on a 300-word minimum for all communication [20:16:58] * sumanah nods at cscott  [20:17:10] Hahaha [20:17:36] sumanah: It was more a friendly jab based on weird changes in communication media standards than a nitpick I think :) [20:17:52] aaaaand a well-actually on a well-actually! marktraceur you certainly have an MO. [20:17:59] * marktraceur :( [20:18:08] I'll stop, terribly sorry to have derailed [20:18:10] and i'll note that [[dent]] is very unhelpful in providing clues about the length you are actually requesting [20:18:36] i assume we are not talking about [[USS Dent (DD-116)]], a United States Navy ship [20:18:44] cscott: OK, I'm sorry for that. Perhaps I should have just said "a sentence is fine" [20:19:14] cscott: Roughly sumanah means "140 characters" I think. Maybe 160. I forget. [20:19:37] https://dev.twitter.com/docs/counting-characters [20:19:52] 140 NFC-normalized unicode codepoints [20:20:28] So, cscott, on https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Scoped_language_converter do you think the question(s) there need answering? [20:21:20] yes, very roughly. [20:21:49] ok - if you have time before the review I imagine you'll answer them onwiki; else I'll ask about them in the meeting. [20:21:52] it's more or less the "category" versus "global" distinction in the RFC, i'm in the process of editing that somewhat to bring it up to date [20:24:19] for [[Square_bounding_boxes]], the summary is: "Visual Editor and others would like to provide square bounding boxes for images and thumbnails, which existing wikitext syntax does not support consistently. I hope to gather consensus around one of the four proposed solutions." [20:25:39] cscott: Thank you muchly [20:27:45] sumanah: oh, and fyi i turn into a pumpkin precisely at 6pm EDT (2200 UTC) because i have to pick up my kid from daycare. [20:27:55] cscott: Understood! [20:59:57] cscott, sumanah: it would be good if you could motivate why we should look into redesigning language variant conversion now [21:00:07] brion: TimStarling hi there [21:00:11] I'll start us off [21:00:11] * brion waves [21:00:17] #startmeeting RfC review (scoped language converter & square bounding boxes) | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours [21:00:17] Meeting started Wed Apr 2 21:00:17 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:17] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:18] The meeting name has been set to 'rfc_review__scoped_language_converter___square_bounding_boxes____channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' [21:00:21] #chair sumanah brion TimStarling [21:00:21] Current chairs: TimStarling brion sumanah [21:00:25] #link: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-02 [21:00:30] Hi all! [21:00:34] #info Today we're covering 2 RfCs, both from C. Scott Ananian: scoped language converter & square bounding boxes [21:00:43] We have to end right at 2200 UTC (6pm East Coast), because C. Scott and I have to head off. [21:00:53] So I'll be timekeeping kind of aggressively [21:00:57] First: [21:00:59] #topic scoped language converter [21:01:05] #link https://www.mediawiki.org/wiki/Requests_for_comment/Scoped_language_converter [21:01:11] #info C. Scott has very significantly revised this RfC from what it was last year! [21:01:24] #info I asked cscott what he'd like out of today's discussion, and he said: "(a) confirm consensus on replacing the existing template-based system with a "glossary" system. (b) discuss how glossaries should interact with templates (page inclusions)" [21:01:36] as Gabriel said just before the meeting started: cscott, sumanah: it would be good if you could motivate why we should look into redesigning language variant conversion now [21:02:16] especially taking into account the discussion on the bug, Parsoid quarterly review & concurrent content translation work [21:02:52] to me it seems that the immediate steps are all fairly clear [21:03:10] the longer term is much less so [21:03:20] would page-scoped rules apply to text that’s passed into templates? [21:03:32] are those immediate steps written out in a comment to https://bugzilla.wikimedia.org/show_bug.cgi?id=41716 or someplace, gwicke? [21:03:37] it's not even clear that language variants are the best solution for e.g. Chinese [21:03:47] sumanah, yup [21:03:52] see the linked bugzilla comment [21:04:33] !link https://bugzilla.wikimedia.org/show_bug.cgi?id=41716#c37 [21:05:26] yeah, so. [21:05:33] I think it makes sense waiting with a grand redesign of the language variant system until it is clear which languages should actually use this [21:05:39] gwicke and i agree on broad details on the new glossary system [21:05:43] brion, yes, unless templates themselves provided their own inline rules. [21:05:44] and how well content translation works at that point [21:06:12] how can you have a chinese wikipedia without language variants? [21:06:14] i think it's fair to say gwicke, i, Eloquence, and others (liangent, etc) all have disagreements about the larger picture of the variant system and how it fits into mediawiki [21:06:26] TimStarling, you can have several Chinese wikipedias [21:06:28] TimStarling: can you have china without taiwan? [21:06:34] are you serious? [21:06:35] right now there is a big cultural split anyway [21:06:45] TimStarling: i am serious. [21:07:00] and editing will always be mixed [21:07:03] it is a huge political issue, which gets conflated with the technical issues. [21:07:10] which does not actually work so well in practice [21:07:12] * cscott would like to redirect this conversation [21:07:41] i don't think it's useful to talk about language variants in general here. nor do i feel like recapping and arguing about whether they are needed, whether color != colour, etc. [21:07:44] are you saying this because people in the chinese wikipedia community want it? [21:08:03] gwicke: https://bugzilla.wikimedia.org/show_bug.cgi?id=41716#c37 is from 6 months ago. What's the status of those steps now? [21:08:07] the mainland community is really small [21:08:09] i'm wiling to get into the variant issues and politics if that is wanted, but i don't think this is a particularly good mechanism to resolve those issues [21:08:15] TimStarling, are you asking gwicke or cscott the questions? [21:08:30] * sumanah probably agrees with cscott about this meeting not being the place to resolve Chinese Wikipedia-related political issues [21:08:36] most of our contributions seem to come from Taiwan etc [21:08:41] uh, what? no. [21:08:47] and I agree with sumanah [21:08:51] and note that variants are used in ~37 different wikis, so zhwiki is not actually the be-all and end-all for variants [21:09:30] you know, we don't have anyone from the WMF language engineering team here and I think if this is so contentious I'd like to give them a chance to read the updated RfC and respond [21:09:45] (cscott made a big revision to the RfC today and they probably haven't had a chance to look) [21:09:47] sure, just need to check how it's actually used in non-Chinese wikis as so far we have mostly focused on Chinese and its requirements [21:10:18] yeah i’d feel a little more comfortable with a better idea of current usage in various languages [21:10:32] generally the idea of scoped rules *sounds* good offhand [21:10:45] but i’ve little experience with the converter and find it hard to say how much this changes usage [21:10:46] cscott: is that something you can work with Amir, Runa, et alia on? getting more stats on current usage in various languages? and maybe Analytics can help [21:10:54] if it's possible, i'd like to table the politics and the issue of whether we want to continue to support variants at all [21:10:55] that'll make this RfC easier to talk about [21:11:03] that's a good discussion to have, and it may well render this entire discussion moot [21:11:23] at the quarterly review we agreed to revisit this after next quarter [21:11:29] but in the interest of separating concerns and making technical progress, i'd like to briefly proceed as if we needed to make variants work, roughly as-is [21:11:36] I'm not a big fan of single-letter rule names [21:11:37] taking into account the content translation work [21:12:12] can we not have human-readable names, like parser functions? [21:12:12] for next quarter we basically plan to add basic editing support as described in the first part of https://bugzilla.wikimedia.org/show_bug.cgi?id=41716#c37 [21:12:13] and just discuss more narrowly the current plan to refactor the existing "huge templates with thousands of rules" into a first-class glossary mechanism [21:12:40] cscott: you mean making zhwiki traditional chinese-only or simplified chinese-only? [21:12:41] gwicke, why is this contingent on content translation work? [21:12:48] conceptually, how does adding new scoped rules differ from turning the existing ‘from this point on’ rules into page-scoped rules? [21:12:57] TimStarling: the human-readable names are not human-readable for non-english speakers. and it's not expected that users are going to be directly interacting with variant syntax. hopefully VE will be providing sugar. [21:13:01] (by "whether we want to continue to support variants at all") [21:13:02] brion, there is no difference [21:13:10] cscott: yes they are [21:13:38] subbu, content translation can make separate wikis easier to support and bootstrap [21:13:53] gwicke, but i am not sure that separate wikis is the answer though. [21:13:57] TimStarling: i'm fine if you want to completely overhaul the variant syntax, but i was trying to make conservative proposals that try to keep what's currently working. [21:14:08] subbu, likely not for all wikis, but probably for some [21:14:28] wctaiwan: there are a number of different proposals. it's a big topic. [21:14:32] possibly which means language variants are going to be needed for the others. [21:14:41] * cscott weeps softly [21:14:47] you are proposing to add another 10 flags or so? [21:15:00] I'm not particularly active on zhwiki, but... dropping variant support is probably a nonstarter. [21:15:06] TimStarling: i'm proposing to get rid of most of the existing flags [21:15:12] only keeping about 3, i think. [21:15:18] do we have a good list of the existing flags? [21:15:32] brion: yes, it's linked at the very top of the rfc [21:15:32] Making zhwiki only available in either zh-hans or zh-hant is almost certainly not going to fly; and I'm dubious whether there'd be support for splitting it at this stage. [21:15:33] wctaiwan, i dont think the proposal is to drop variant support but to clean it up to make it more easy to maintain and support (including VE support). [21:15:37] wctaiwan, because the editor community would be too small for separate wikis? [21:15:39] aha [21:15:55] wctaiwan: the whole idea of variants was invented by chinese people for the purposes of making a unified chinese wiki [21:16:09] gwicke: I suggest consulting the community there before making any decision on this. [21:16:23] TimStarling: that's true for mediawiki, but not true in general [21:16:27] I suggested splitting them, but Andrew Lih in particular was very keen to keep things together [21:16:29] so, this sounds like something that needs input from Alolita's team, and from liangent -- I asked Liangent to comment at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Scoped_language_converter but she wouldn't have had time to comment on the updated RfC before the meeting [21:16:30] wctaiwan, certainly [21:16:38] there are lots of different communities which use language variants for one purpose or another [21:16:39] it was pointed out after the block that there wasn't much mainland editing [21:16:52] arguably en-us and en-gb could use variants, if it were well integrated and supported. [21:16:52] liangent is a very good person to ask; he's a sysop on zhwiki, iirc. [21:17:01] the response to that was that most users who want the simplified variant are actually in the US and other expat communities [21:17:09] wctaiwan, we have discussed this a lot with her [21:17:13] and that these expat communities are roughly on the same scale as taiwan [21:17:13] he'd be much more aware of how the community feels than I am (I'm mostly enwiki) [21:17:25] other communities use it because there are multiple different scripts, or there are large dialect differences that don't quite rise to the level of requiring a separate wiki [21:18:14] Would everyone be okay with us temporarily stopping this discussion here in this meeting to try to gather input from WMF Lang Eng + liangent onlist, hopefully in the next few days to help C. Scott not get stopped for too long? [21:18:15] TimStarling: possibly; and also, zhwiki is not actually blocked by the GFW at the moment (HTTPS access is though; if I recall correctly), so there's no real reason why there can't be more editors from china. [21:18:36] for that matter, the existing language converter is a mix of script conversion and rule-based "word" conversion; those features can/should be separated. but that's not strictly relevant to the rule syntax in the RFC. [21:18:41] sumanah, we basically have enough work for a quarter or so already [21:18:52] sumanah: i would be fine with pausing the discussion until wikimania. [21:18:56] without touching the existing implementation [21:19:20] wctaiwan: we have been talking to liangent, she has been very helpful. [21:19:43] cscott: it would be great if you could get her to comment/endorse on the talk page or onlist if she can't come to a mtg [21:19:55] or we can schedule an upcoming mtg in a time she can attend [21:20:01] sumanah: she has commented on the various bugs. this is 5am her time, though. [21:20:18] see for exampel https://bugzilla.wikimedia.org/show_bug.cgi?id=41716#c40 [21:20:38] yeah, she mentioned this was a bad time for her and I asked whether she could comment on the talkpage ahead of time. Maybe she will listen to you and not me! :) or maybe she just didn't realize we'd want her stamp of approval :) [21:20:49] cscott: okay :) all I'm saying is that this really isn't a purely technical decision; I just don't want people to say "the technical merits of dropping variant support are huge, so let's" [21:20:49] anyway, what i really want to know is how we can make progress when there is so much disagreement and misunderstanding [21:21:04] wctaiwan: oh yes, i totally agree with you [21:21:12] if zhwiki is okay with splitting, that might work, but otherwise I think some form of variant support needs to continue to exist. [21:21:25] ….and those other languages too… [21:21:27] well, there's not really any controversy on the idea of scoped rules [21:21:30] so you could just do that [21:21:31] there are not many people who actually understand how variants are used in the ~30 different wikis where it is enabled [21:21:42] the scope as discussed so far has been the page [21:21:44] cscott: have you already asked Amir Aharoni for advice here? this seems like classic Product Manager fodder [21:22:02] I thought you were adding a load more rules, which made me think that you should be switching the system over to MagicWord so that it's not quite so stupid [21:22:14] but if not, I guess it can stay like it is [21:22:29] our plan as discussed at the meeting was to move all page-wide rules out of the page content itself [21:22:35] sumanah: i talked to amir last time i was in SFO, and with Eloquence as well. [21:22:36] and only allow once-only inline rules [21:23:11] and gwicke, subbu, and i, with input from liangent, locked ourselves in a room until we came up with the working plan embodied in the bug. [21:23:32] gwicke: when i was revising the RFC i realized there were a number of issues left unsettled [21:23:52] that included roan and david as well. [21:23:54] like: how do rules in templated content work? [21:23:55] I abandoned my very similar RFC after that meeting [21:24:17] and there is no talk of dropping variant support in that plan. so confused how that came up here today. [21:24:18] cscott, our agreement back then was just as in page content [21:24:20] gwicke: how do we resolve conflicts between rules? [21:24:29] how are you going to deal with old text? [21:24:37] converting templates etc.? [21:24:46] #info much discussion about Chinese Wikipedia(s), language variant usage (we don't have enough stats probably about this), existing Parsoid team plans, community consensus issues [21:24:55] TimStarling: we have a proposal for a linting system based on checkwiki [21:25:13] for zhwiki, at least, the existing template-based system is actually very regularly structured; they have tools that work on it, etc. [21:25:24] so you would support the old rules for some deprecation period? [21:25:25] so it should be straightforward to migrate, once we decide how we want to do so [21:25:50] TimStarling: yes, to some extent. [21:26:03] it turns out that some of the nastier features of the current system aren't actually widely used [21:26:19] and at some point the old rule variants would cease to parse? or be turned into invisible? or? [21:26:26] I don't see a good reason to introduce new syntax now [21:26:39] for example, the way that rules currently apply "from point of definition on" is rather tricky to do -- but on zhwiki all the rules are typically defined at the very top of the page. [21:26:56] which effectively make them page-level rules. [21:27:43] yup, the plan is to move them out of the page [21:27:53] so you could make the existing rules page-level without breaking too much? [21:28:10] you'd still have to move them out [21:28:23] So, this is a super wide-ranging discussion and I'm calling time [21:28:24] but that can be a gradual process [21:28:35] I discussed some of that at https://www.mediawiki.org/wiki/Requests_for_comment/Page_and_category_based_language_variant_conversion [21:28:37] and use the Parsoid-based linting system to flag problematic scenarios. [21:28:39] TimStarling: yes -- but i'm concerned there are some template issues that need to be resolved. [21:29:09] we need to move on so that we can talk about the other RfC today and so cscott and I can get out of here in 30 min and so others from zhwiki(s) & Lang Eng can comment. So I'm about to switch #topic [21:29:24] it's not clear whether rules defined in a page apply to templates included in the page, and/or whether rules defined in a template apply to the broader page. [21:29:42] provisionally we would like the answer to be "yes" and "no" [21:29:45] #agreed more discussion onlist [21:29:47] :) [21:29:56] #topic square bounding boxes [21:29:56] #link https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes [21:30:02] #info "The current mediawiki syntax for image thumbnails and resizing works poorly for images which are taller than they are wide." [21:30:10] #info "The upright option attempts to remedy this, but properly scaling an thumbnail to fit a square bounding box requires the user to manually compute the aspect ratio of the image. There is no way to directly limit or scale a thumbnail based on height. [21:30:14] " [21:30:15] cscott, last time we discussed this it was 'yes' and 'no' [21:30:24] #info C. Scott would like for us to weigh four proposals for remedying this situation: [21:30:24] #info 1) Change mediawiki to use square bounding boxes by default (opt-out). [21:30:24] #info 2) Add a new image option to request a square bounding box (opt-in). Proposed implementation in changeset https://gerrit.wikimedia.org/r/120856 which has not been merged yet. [21:30:24] #info 3) Add a new "upright=auto" option (minimalist, opt-in) [21:30:24] #info 4) Add a new "scale=N" option (adds new functionality, opt-in) [21:30:33] gwicke: can templates use glossaries at all? [21:30:46] cscott, only the global ones associated with the page [21:30:48] #info cscott says about today's discussion: "Visual Editor and others would like to provide square bounding boxes for images and thumbnails, which existing wikitext syntax does not support consistently. I hope to gather consensus around one of the four proposed solutions." [21:31:05] and once-only inline rules [21:31:13] bawolff: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140402.txt has the logs up till now [21:31:13] gwicke: and i agree with 'yes' and 'no' i'm just pointing out that the current system is "mostly yes" and "mostly yes" (from point of definition on), and that could lead to issues migrating content. [21:31:26] Thanks [21:31:44] jorm: maybe you have an opinion on this? (the bounding boxes) [21:31:45] don’t we already support square bounding boxes? [21:31:48] [[file:foo|300x300px]] [21:31:55] we don't support square bounding boxes for thumbnails of default size [21:32:06] shouldn’t that simply be a change to the default behavior? [21:32:23] brion: that's one of the proposals in the rfc, yes. [21:32:26] that's my preference too [21:32:37] proposal #1, in fact. [21:32:42] * bawolff doesnt actually see what the problem is [21:32:46] furthermore, do we really mean *square*? [21:32:53] or do we mean “something with a defined maximum height”? [21:33:03] eg 220x180 or whatever [21:33:03] brion: yes. we mean, we limit width or height, *whichever is larger* [21:33:04] don't forget the 'bounding box' part [21:33:07] #1 would break about 10 million pages for no real reason [21:33:31] TimStarling: how so? [21:33:32] TimStarling, existing content would need to be adapted [21:33:42] but that's fairly easy to automate [21:33:43] TimStarling: somewhat less than that, as it would only affect non-landscape images, and there are not that many of those [21:33:50] the more interesting cases are in templates [21:34:08] we'd need to investigate whether a width-only restriction is still needed there [21:34:15] certainly not very many non-landscape images which aren't already using explicit sizes [21:34:18] and how we could provide that if needed [21:34:20] I don't see how you would automate it [21:34:49] brion: #1 isn't just a proposal to change the default thumbnail size [21:35:00] TimStarling, it's fairly easy to keep current sizes [21:35:03] TimStarling: parse page, for every image fetch imageinfo, if imageinfo says non-landscape, tweak image options to preserve current size. [21:35:04] [[File:foo.jpg|thumb]] can have a square bounding box, that is fine [21:35:09] that doesn't break much [21:35:30] the proposal is to make [[File:foo.jpg|thumb|200px]] have a square bounding box [21:35:30] what we discussed so far was to have an optional scale factor [21:35:43] that can be used to change the relative bbox size similar to upright [21:35:48] so the effect of that would be that tall images might change from 200px wide to smaller [21:35:54] yes [21:36:06] so to avoid breaking layout, you would have to edit every such image inclusion [21:36:06] I could be on-board with "proposal 1a", "only change [[File:foo.jpg|thumb]] to have a square bounding box" [21:36:15] that's the simplest possible thing that would help [21:36:29] i’m happy to break layout in this way, it doesn’t bother me offhand [21:36:34] gwicke: that's proposal #4, right? [21:36:52] cscott, is #4 default square too? [21:37:06] gwicke: "In this version of the proposal, we add a new "scale" option, which is a better replacement for "upright" and uses a square bounding box by default." [21:37:19] so without scale the bbox is not square? [21:37:32] gwicke: that's my understanding of the proposal [21:37:34] that would run into the inconsistency issues we discussed before [21:38:01] gwicke: feel free to suggest a variant. proposal #4 was supposed to match your proposal, perhaps i misunderstood it. [21:38:04] that's why I proposed to move to square by default with the optional scale parameter [21:38:37] gwicke: i don't understand. can you elaborate? [21:38:52] i’m not sure i understand the scale factor [21:38:52] option 1 and 4 combined [21:39:19] the scale factor works basically like upright [21:39:28] Won't that change a whole lot of things for the user, though? In terms of what they got used to / expect vs. how things will behave ? [21:39:36] it scales relative to the default size [21:39:52] the default size when not thumbnailed is hard to predict [21:40:02] the problem with #4 is that adding scale now also magically changes the bbox from width-only to square [21:40:02] since it can change if the image is rescaled and reuploaded [21:40:24] Default size as in user option, or default as in natural unscaled size [21:40:27] ? [21:40:45] which might be thousands of pixels, for the latter [21:40:52] only for scaled versions [21:41:20] there is a related discussion about more semantic image types [21:41:20] TimStarling: the problem with proposal "1b" is that it will make 'upright' even more unusual. [21:41:20] beyond thumb [21:41:29] scale could apply to those too, or those semantic classes could actually replace scale [21:42:07] I'm assuming the underlying problem that's being solved is that you're trying to make sure Parsoid output has reasonable semantics, right? [21:42:18] TimStarling: either 'upright' also uses a square bounding box, which means that it is only/exactly the same as "scale" and lots of portrait images currently using 'upright' will change size, or else upright is (counterintuitively) a width-based bound, where 'thumb' is a square bound [21:42:22] I like the idea of moving towards more semantic image types, but am sceptical about some uses cases in templates [21:42:44] robla, our output can have nice semantics already [21:42:47] wait, whut? bounding boxes? [21:42:51] the problem is that we have to abuse upright [21:43:09] when images are re-uploaded, the image size can change drastically [21:43:37] So what is the problem this is trying to solve? [21:43:46] we are promising a square bounding box already, but when the image's aspect ratio changes later wikitext does not let us enforce that contract currently [21:44:14] I was not involved with the upright option and so it's hard for me to say exactly what should be done with it [21:44:34] and, more fundamentally, 'upright' was added to allow galleries to use consistent square bounding boxes for images of various aspect ratios -- but it utterly fails in that purpose currently, as it is still a width bound, not a height bound. [21:44:53] 'upright' should be thrown from a bridge. [21:44:59] :D [21:45:02] also many new images are no longer 3:4 aspect ratio [21:45:02] by which i mean, "deprecated". but that's offtopic. [21:45:21] so fundamental question: [21:45:29] why is a square bounding box being promised when it’s not delivered? [21:45:34] just to recap -- upright uses the same *width-based* scaling as thumb, but adds an additional scaling factor, by default 0.75. [21:46:01] I think [[File:Foo.jpg|thumb]] means "make it whatever smallish size the user wants" [21:46:02] if you manually compute the aspect ratio of your image, you can set "upright=" to get a consistent square size [21:46:18] brion, wikitext lets you specify any bounding box you like [21:46:20] so there's no expectation of b/c [21:46:20] i kind of like the third option from the RFC, per what TimStarling just said [21:46:27] but of course that fails if a new version of the image has a different aspect ratio, or if you're too lazy to manually compute the proper aspect ratio. [21:46:42] it does not make much sense though in something like VE to edit a bounding box separately from the actual dimensions [21:46:46] but [[File:Foo.jpg|thumb|200px]] means "make this have a width of exactly 200px" [21:46:57] changing the behavior of 'thumb' will likely be acceptable, changing the behavior of pixel sizes would wreak havoc i'm afraid [21:46:59] note that the code goes to some effort to make sure that it is never 199px or 201px [21:47:11] (also because these are used for UI elements, main page designs, etc etc) [21:47:14] so I think there is a b/c expectation with that syntax [21:47:16] TimStarling: not actually the case. 'upright' has that rounding code, but not thumb. [21:47:33] what rounding code? [21:47:43] * cscott is the world expert in the broken semantics of image options in wikitext [21:47:46] if you specify a width of 200, it's 200 [21:47:52] there's no rounding [21:47:54] if you specify a width of 199, it's 199 [21:48:00] ? [21:48:01] yes [21:48:12] if you specify a width of 199 by using 'upright=0.9' (or whatever the proper factor is), you actually get 200 [21:48:17] because it rounds to the nearest 10px [21:48:21] *rounds the width [21:48:23] we are mostly talking about thumb & upright [21:48:23] at this point i’m very confused and still don’t understand the fundamental problem being solved by this rfc [21:48:37] parsoid alway emits square bounding boxes for non-upright images [21:48:42] so 200x200px [21:48:44] * AaronSchulz sits at brion's camp fire [21:48:44] Does anyone actually use upright in the wild [21:48:48] TimStarling: that's the only case I know of where " the code goes to some effort to make sure that it is never 199px or 201px" [21:49:03] because ive never seen it used [21:49:08] TimStarling: oh, but you mean that if you specify 200px you get 200px, not that the code rounds the value you ask for. [21:49:17] and it seems poorly thought out [21:49:32] bawolff, we see it quite often [21:49:38] bawolff: it is, unfortunately, very common in some wikis. [21:49:42] I feel like I need diagrams to understand the current situation and what we might want instead [21:49:48] gwicke: doesn't {{Largethumb}} use it? [21:49:57] cscott: yes [21:50:00] cscott: ok. Just checking [21:50:11] afaik largethumb actually sets a px size [21:50:19] gwicke: well, that's good ;) [21:50:32] https://nl.wikipedia.org/wiki/Sjabloon:Largethumb [21:50:35] 260px|thumb [21:50:37] anyway, where I am going with this is that I am not happy with changing the width of images with a width or complete bounding box specified [21:50:49] bawolff, frwiki uses upright a lot from waht i udnerstand [21:50:51] anyway, i can certainly easily implement the "thumb uses a square bounding box if no other is requested" semantics. that's pretty straightforward. [21:50:52] but I'm undecided on the other proposals [21:51:04] cscott, upright has rounding to the nearest multiple of 10px. [21:51:13] mooeypoo: yes [21:51:38] TimStarling, we are mostly concerned about images without px sizes [21:51:48] so either bare thumb or thumb + upright [21:51:48] TimStarling: changing the default semantics of bare '200px' was an attempt to make the output of VE/Parsoid prettier. It always emits square bounding boxes, and some users felt that "200x200px" was ugly in the wikitext. [21:51:50] fwiw [21:52:10] cscott: let it be ugly [21:52:22] gwicke: so if theres’s not a known size, don’t emit one? [21:52:29] is that a feasible option? [21:52:47] TimStarling: that's fine with me. i'm just explaining why that part of proposal #1 was present. [21:52:47] cscott: why does Parsoid do that, actually? (honest question) [21:52:48] Making bare thumb take both dimensions into account sounds sensible to me personally [21:52:58] my personal preference was proposal #2, but nobody but me likes that one. ;) [21:53:04] yes, the question is 1) what's the bounding box for those images, and b) can we scale relative to a square bounding box? [21:53:37] MatmaRex: it matches what users actually want to do, and it avoids forward-propagating the evil tarpit of wikitext image options. [21:54:00] it seems like the answer to ‘what’s the bounding box of an image with “thumb” generic size’ is “whatever the output system wants it to be, based on site/user preferences and the aspect ratio of the image" [21:54:06] which is to say, it’s not parsoid’s problem [21:54:07] hmmm. ooookay. [21:54:36] OK, we have like 5 more min here. Any conclusions? [21:54:48] brion, i think the current issue is that the default wiki size outputs width-only restriction, not a bounding box? [21:54:56] it seems like if i change the default behavior of bare 'thumb' that might have a chance to get merged [21:55:07] mooeypoo: the default wiki size is the natural size of the image if nothing is specified [21:55:11] brion, right now we'd have to use an upright factor to make it render at the expected (square bounding box) size [21:55:16] if i also change the behavior of 'upright' to use a square bounding box, it would make the semantics much nicer, but would be more controversial. [21:55:20] if ‘thumb’ is specified, then a width based on site configuration and user prefs is used [21:55:34] cscott: I wonder how many pages use upright [21:55:45] brion, aye, but in thumbnails, it's a specific width given by default and overridden in wiki wgUserOptions[thumbsize] IIRC [21:55:54] gwicke: it really seems like this isn’t parsoid’s concern, but the level of the layer on top of that that creates presentation-ready markup in a skin etc [21:55:57] TimStarling: I can answer that question, but not online. [21:56:09] brion, it's a WYSIWYG problem [21:56:14] maybe we can shove the cat back in the bag with that one [21:56:46] gwicke: the WYSIWYG editor is an extension to MediaWiki, which knows the image sizes and the site configuration and the user preferences, so it can size appropriately [21:56:56] TimStarling: i've got a number of similar image option fixes pending (https://gerrit.wikimedia.org/r/116995, https://gerrit.wikimedia.org/r/119332) that are just waiting for me to spend some quality time with parsoid dumpGrepper tool to figure out whether the changes break too many pages. [21:57:00] TimStarling, apparently frwiki recommends use of upright ... according to this: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#.22Frame.22_option [21:57:37] brion, we opted to make life for VE and other editors easy by giving them an easy square bounding box model [21:57:46] even changing to a square bounding box for 'upright' only matters if the image in question is non-landscape. so even where upright is widely used, it might not change as many pages as it seems to. [21:57:53] gwicke: if the bounding box were removed, what would be the result? [21:57:54] so it's our task to deal with the impedance mismatch [21:58:03] ok. i have to turn into a pumpkin soon, my kid needs to be picked up from daycare. [21:58:08] So the answer to "any conclusions?" sounds like "nothing that can be snappily articulated" :) [21:58:17] :) [21:58:25] it seems like i've got roughly a two patch roadmap here: first change bare 'thumb' and then secondly make 'upright' match. [21:58:38] do we want to have cscott do those 2 patches, get more input onlist & onwiki and return to this next week? [21:58:42] imo ‘upright’ should behave as ‘thumb’ with the width and height switched [21:58:48] and ‘thumb’ should include a height as well as a width [21:58:50] #action cscott to patch bare "thumb" to have square bounding box [21:58:54] brion, we'd emit weird px sizes everywhere, which would not do what you want when the image changes from landscape to portrait [21:59:06] brion: that matches how it was originally documented, but *not* how it was actually implemented. [21:59:07] gwicke: why emit any px sizes? [21:59:12] someone else can summarise the upright thing, I don't get it [21:59:21] brion, you mean don't support resizing thumbs? [21:59:35] #info pixel sizes, 'upright', strange conversions, and other issues occasion much comment and confusion [21:59:40] gwicke: i mean leave default-size images at whatever the default is going to be [21:59:44] Brion: so upright becomes the equiv of putting an x in front of the size [21:59:45] and not enforce it at the editor level [21:59:53] we gotta go, all [21:59:54] brion, that's what we are already doing [21:59:55] #action cscott to patch upright to have a square bounding box, and use dumpGrepper to see whether this breaks too much [21:59:59] let's talk more onlist/onwiki [22:00:02] then i’m super confused wheret he boxes come from :D [22:00:04] #endmeeting [22:00:04] Meeting ended Wed Apr 2 22:00:04 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:00:04] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-02-21.00.html [22:00:04] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-02-21.00.txt [22:00:04] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-02-21.00.wiki [22:00:05] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-02-21.00.log.html [22:00:15] brion, it's tricky ;) [22:00:17] sumanah: thanks [22:00:17] hehe [22:00:20] * subbu is glad i am not th eonly one confused [22:00:26] ok i’ll have to fiddle around and do some more research on this [22:00:34] i gotta brush up on VE and parsoid anyway :D [22:00:41] bawolff: yes, but upright also takes a scale factor. for no good reason. [22:00:45] oh is this sort of thing Brion bait? :) [22:00:52] :D [22:00:56] let's let cscott pick his kid up :) [22:00:59] for all you wondering, here is our DOM spec documenting all this: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images [22:00:59] * cscott has to run, kid is waiting [22:00:59] thanks all [22:01:01] yep [22:01:05] thanks everybody for participating! [22:01:11] gwicke: although i haven't updated that with the new hotness yet [22:01:28] thanks for suffering through languageconverter everyone, and for helping reach some sort of plan for thumb/upright. [22:01:36] ok i gotta run, be back on regular channels in a bit [22:01:49] i'll check backlog when i return, in case you've got any lingering qs [22:02:17] cscott, we'll need data on how many images would change dimensions [22:02:36] and possibly a strategy to update them [23:18:45] gwicke: it's possible that if we change the default upright scaling factor to 1 at the same time we make it use a square bounding box, we'll preserve the existing size of all the 4:3 images as well. [23:32:06] that's one way to do it, yet ;) [23:32:11] yes [23:32:49] or we'd use legacy behavior for upright [23:33:14] I'm more concerned about portrait thumbs without upright