Architecture meetings/RFC review 2014-04-02

2100 UTC, 2 April, at.

Requests for Comment to review

 * 1) Scoped language converter - C. Scott Ananian
 * 2) Square bounding boxes - C. Scott Ananian

Summary and logs

 * LINK: : https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-02 (sumanah, 21:00:25)
 * Today we're covering 2 RfCs, both from C. Scott Ananian: scoped language converter & square bounding boxes (sumanah, 21:00:34)
 * scoped language converter (sumanah, 21:00:59)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Scoped_language_converter (sumanah, 21:01:05)
 * C. Scott has very significantly revised this RfC from what it was last year! (sumanah, 21:01:11)
 * 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)" (sumanah, 21:01:24)
 * 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 (sumanah, 21:24:46)
 * AGREED: more discussion onlist (sumanah, 21:29:45)


 * square bounding boxes (sumanah, 21:29:56)
 * LINK: https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes (sumanah, 21:29:57)
 * "The current mediawiki syntax for image thumbnails and resizing works poorly for images which are taller than they are wide." (sumanah, 21:30:02)
 * "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. (sumanah, 21:30:10)
 * C. Scott would like for us to weigh four proposals for remedying this situation: (sumanah, 21:30:24)
 * 1)  Change mediawiki to use square bounding boxes by default (opt-out).  (sumanah, 21:30:24)
 * 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.  (sumanah, 21:30:24)
 * 3)   Add a new "upright=auto" option (minimalist, opt-in)  (sumanah, 21:30:24)
 * 4)   Add a new "scale=N" option (adds new functionality, opt-in)  (sumanah, 21:30:24)
 * 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."  (sumanah, 21:30:48)
 * LINK: https://nl.wikipedia.org/wiki/Sjabloon:Largethumb (gwicke, 21:50:32)
 * ACTION: cscott to patch bare "thumb" to have square bounding box (TimStarling, 21:58:50)
 * pixel sizes, 'upright', strange conversions, and other issues occasion much comment and confusion (sumanah, 21:59:35)
 * ACTION: cscott to patch upright to have a square bounding box, and use dumpGrepper to see whether this breaks too much (cscott, 21:59:55)

Meeting ended at 22:00:04 UTC.

Action items

 * cscott to patch bare "thumb" to have square bounding box
 * cscott to patch upright to have a square bounding box, and use dumpGrepper to see whether this breaks too much

Full log
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:17  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:51 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 <TimStarling> well, there's not really any controversy on the idea of scoped rules 21:21:30 <TimStarling> 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 <TimStarling> 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 <TimStarling> 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 <TimStarling> how are you going to deal with old text? 21:24:37 <TimStarling> 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 <TimStarling> 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 <TimStarling> 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:36 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:57 #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 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 <TimStarling> #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 <TimStarling> I don't see how you would automate it 21:34:49 <TimStarling> 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 <TimStarling> can have a square bounding box, that is fine 21:35:08 <TimStarling> that doesn't break much 21:35:30 <TimStarling> the proposal is to make 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 <TimStarling> yes 21:36:06 <TimStarling> 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 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:50 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 <TimStarling> 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 <TimStarling> I think 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 <TimStarling> so there's no expectation of b/c 21:46:20 <MatmaRex> 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 <TimStarling> but means "make this have a width of exactly 200px" 21:46:57 <MatmaRex> changing the behavior of 'thumb' will likely be acceptable, changing the behavior of pixel sizes would wreak havoc i'm afraid 21:46:59 <TimStarling> note that the code goes to some effort to make sure that it is never 199px or 201px 21:47:11 <MatmaRex> (also because these are used for UI elements, main page designs, etc etc) 21:47:14 <TimStarling> 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 <TimStarling> what rounding code? 21:47:43 * cscott is the world expert in the broken semantics of image options in wikitext 21:47:46 <TimStarling> if you specify a width of 200, it's 200 21:47:52 <TimStarling> there's no rounding 21:47:54 if you specify a width of 199, it's 199 21:48:00 <AaronSchulz> ? 21:48:01 <TimStarling> 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 use it? 21:49:57 <TimStarling> 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 <TimStarling> 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 <TimStarling> 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 <TimStarling> 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 <MatmaRex> 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 <MatmaRex> 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 <TimStarling> 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 <TimStarling> 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 <subbu_ss> 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 <TimStarling> #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 <TimStarling> 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:58 let's talk more onlist/onwiki 22:00:02 then i’m super confused wheret he boxes come from :D 22:00:04 #endmeeting

brion, it's tricky ;) sumanah: thanks hehe ok i’ll have to fiddle around and do some more research on this i gotta brush up on VE and parsoid anyway :D bawolff: yes, but upright also takes a scale factor. for no good reason. oh is this sort of thing Brion bait? :) :D let's let cscott pick his kid up :) thanks all for all you wondering, here is our DOM spec documenting all this: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images yep thanks everybody for participating! gwicke: although i haven't updated that with the new hotness yet thanks for suffering through languageconverter everyone, and for helping reach some sort of plan for thumb/upright. ok i gotta run, be back on regular channels in a bit i'll check backlog when i return, in case you've got any lingering qs cscott, we'll need data on how many images would change dimensions
 * subbu is glad i am not th eonly one confused
 * cscott has to run, kid is waiting
 * brion has quit (Quit: brion)

and possibly a strategy to update them