Architecture meetings/RFC review 2014-04-02
2100 UTC, 2 April, at #wikimedia-office connect.
Requests for Comment to review
[edit]- Scoped language converter - C. Scott Ananian
- Square bounding boxes - C. Scott Ananian
Summary and logs
[edit]- 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
[edit]- 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
[edit]| Meeting logs |
|---|
21:00:17 <sumanah> #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 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:17 <wm-labs-meetbot> 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 <sumanah> #chair sumanah brion TimStarling
21:00:21 <wm-labs-meetbot> Current chairs: TimStarling brion sumanah
21:00:25 <sumanah> #link: https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-02
21:00:30 <sumanah> Hi all!
21:00:34 <sumanah> #info Today we're covering 2 RfCs, both from C. Scott Ananian: scoped language converter & square bounding boxes
21:00:43 <sumanah> We have to end right at 2200 UTC (6pm East Coast), because C. Scott and I have to head off.
21:00:53 <sumanah> So I'll be timekeeping kind of aggressively
21:00:57 <sumanah> First:
21:00:59 <sumanah> #topic scoped language converter
21:01:05 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Scoped_language_converter
21:01:11 <sumanah> #info C. Scott has very significantly revised this RfC from what it was last year!
21:01:24 <sumanah> #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 <sumanah> as Gabriel said just before the meeting started: <gwicke> cscott, sumanah: it would be good if you could motivate why we should look into redesigning language variant conversion now
21:02:16 <gwicke> especially taking into account the discussion on the bug, Parsoid quarterly review & concurrent content translation work
21:02:51 <gwicke> to me it seems that the immediate steps are all fairly clear
21:03:10 <gwicke> the longer term is much less so
21:03:20 <brion> would page-scoped rules apply to text that’s passed into templates?
21:03:32 <sumanah> 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 <gwicke> it's not even clear that language variants are the best solution for e.g. Chinese
21:03:47 <gwicke> sumanah, yup
21:03:52 <gwicke> see the linked bugzilla comment
21:04:33 <sumanah> !link https://bugzilla.wikimedia.org/show_bug.cgi?id=41716#c37
21:05:26 <cscott> yeah, so.
21:05:33 <gwicke> 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 <cscott> gwicke and i agree on broad details on the new glossary system
21:05:43 <subbu> brion, yes, unless templates themselves provided their own inline rules.
21:05:44 <gwicke> and how well content translation works at that point
21:06:12 <TimStarling> how can you have a chinese wikipedia without language variants?
21:06:14 <cscott> 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 <gwicke> TimStarling, you can have several Chinese wikipedias
21:06:28 <cscott> TimStarling: can you have china without taiwan?
21:06:34 <TimStarling> are you serious?
21:06:35 <gwicke> right now there is a big cultural split anyway
21:06:45 <cscott> TimStarling: i am serious.
21:07:00 <gwicke> and editing will always be mixed
21:07:03 <cscott> it is a huge political issue, which gets conflated with the technical issues.
21:07:10 <gwicke> which does not actually work so well in practice
21:07:12 * cscott would like to redirect this conversation
21:07:41 <cscott> 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 <TimStarling> are you saying this because people in the chinese wikipedia community want it?
21:08:03 <sumanah> 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 <gwicke> the mainland community is really small
21:08:09 <cscott> 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 <subbu> 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 <gwicke> most of our contributions seem to come from Taiwan etc
21:08:41 <wctaiwan> uh, what? no.
21:08:47 <wctaiwan> and I agree with sumanah
21:08:51 <cscott> 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 <sumanah> 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 <sumanah> (cscott made a big revision to the RfC today and they probably haven't had a chance to look)
21:09:47 <gwicke> 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 <brion> yeah i’d feel a little more comfortable with a better idea of current usage in various languages
21:10:32 <brion> generally the idea of scoped rules *sounds* good offhand
21:10:45 <brion> but i’ve little experience with the converter and find it hard to say how much this changes usage
21:10:46 <sumanah> 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 <cscott> 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 <sumanah> that'll make this RfC easier to talk about
21:11:03 <cscott> that's a good discussion to have, and it may well render this entire discussion moot
21:11:23 <gwicke> at the quarterly review we agreed to revisit this after next quarter
21:11:29 <cscott> 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 <TimStarling> I'm not a big fan of single-letter rule names
21:11:37 <gwicke> taking into account the content translation work
21:12:12 <TimStarling> can we not have human-readable names, like parser functions?
21:12:12 <gwicke> 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 <cscott> 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 <wctaiwan> cscott: you mean making zhwiki traditional chinese-only or simplified chinese-only?
21:12:41 <subbu> gwicke, why is this contingent on content translation work?
21:12:48 <brion> conceptually, how does adding new scoped rules differ from turning the existing ‘from this point on’ rules into page-scoped rules?
21:12:57 <cscott> 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 <wctaiwan> (by "whether we want to continue to support variants at all")
21:13:02 <gwicke> brion, there is no difference
21:13:10 <TimStarling> cscott: yes they are
21:13:38 <gwicke> subbu, content translation can make separate wikis easier to support and bootstrap
21:13:53 <subbu> gwicke, but i am not sure that separate wikis is the answer though.
21:13:57 <cscott> 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 <gwicke> subbu, likely not for all wikis, but probably for some
21:14:28 <cscott> wctaiwan: there are a number of different proposals. it's a big topic.
21:14:32 <subbu> possibly which means language variants are going to be needed for the others.
21:14:41 * cscott weeps softly
21:14:47 <TimStarling> you are proposing to add another 10 flags or so?
21:15:00 <wctaiwan> I'm not particularly active on zhwiki, but... dropping variant support is probably a nonstarter.
21:15:06 <cscott> TimStarling: i'm proposing to get rid of most of the existing flags
21:15:12 <cscott> only keeping about 3, i think.
21:15:18 <brion> do we have a good list of the existing flags?
21:15:32 <cscott> brion: yes, it's linked at the very top of the rfc
21:15:32 <wctaiwan> 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 <subbu> 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 <gwicke> wctaiwan, because the editor community would be too small for separate wikis?
21:15:39 <brion> aha
21:15:55 <TimStarling> wctaiwan: the whole idea of variants was invented by chinese people for the purposes of making a unified chinese wiki
21:16:09 <wctaiwan> gwicke: I suggest consulting the community there before making any decision on this.
21:16:23 <cscott> TimStarling: that's true for mediawiki, but not true in general
21:16:27 <TimStarling> I suggested splitting them, but Andrew Lih in particular was very keen to keep things together
21:16:29 <sumanah> 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 <gwicke> wctaiwan, certainly
21:16:38 <cscott> there are lots of different communities which use language variants for one purpose or another
21:16:39 <TimStarling> it was pointed out after the block that there wasn't much mainland editing
21:16:52 <cscott> arguably en-us and en-gb could use variants, if it were well integrated and supported.
21:16:52 <wctaiwan> liangent is a very good person to ask; he's a sysop on zhwiki, iirc.
21:17:01 <TimStarling> 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 <gwicke> wctaiwan, we have discussed this a lot with her
21:17:13 <TimStarling> and that these expat communities are roughly on the same scale as taiwan
21:17:13 <wctaiwan> he'd be much more aware of how the community feels than I am (I'm mostly enwiki)
21:17:25 <cscott> 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 <sumanah> 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 <wctaiwan> 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 <cscott> 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 <gwicke> sumanah, we basically have enough work for a quarter or so already
21:18:52 <cscott> sumanah: i would be fine with pausing the discussion until wikimania.
21:18:56 <gwicke> without touching the existing implementation
21:19:20 <cscott> wctaiwan: we have been talking to liangent, she has been very helpful.
21:19:43 <sumanah> 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 <sumanah> or we can schedule an upcoming mtg in a time she can attend
21:20:01 <cscott> sumanah: she has commented on the various bugs. this is 5am her time, though.
21:20:18 <gwicke> see for exampel https://bugzilla.wikimedia.org/show_bug.cgi?id=41716#c40
21:20:38 <sumanah> 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 <wctaiwan> 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 <cscott> anyway, what i really want to know is how we can make progress when there is so much disagreement and misunderstanding
21:21:04 <cscott> wctaiwan: oh yes, i totally agree with you
21:21:12 <wctaiwan> 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 <brion> ….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 <cscott> there are not many people who actually understand how variants are used in the ~30 different wikis where it is enabled
21:21:42 <gwicke> the scope as discussed so far has been the page
21:21:44 <sumanah> 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 <gwicke> our plan as discussed at the meeting was to move all page-wide rules out of the page content itself
21:22:35 <cscott> sumanah: i talked to amir last time i was in SFO, and with Eloquence as well.
21:22:36 <gwicke> and only allow once-only inline rules
21:23:11 <cscott> 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 <cscott> gwicke: when i was revising the RFC i realized there were a number of issues left unsettled
21:23:52 <subbu> that included roan and david as well.
21:23:54 <cscott> like: how do rules in templated content work?
21:23:55 <gwicke> I abandoned my very similar RFC after that meeting
21:24:17 <subbu> and there is no talk of dropping variant support in that plan. so confused how that came up here today.
21:24:18 <gwicke> cscott, our agreement back then was just as in page content
21:24:20 <cscott> 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 <sumanah> #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 <cscott> TimStarling: we have a proposal for a linting system based on checkwiki
21:25:13 <cscott> 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 <cscott> so it should be straightforward to migrate, once we decide how we want to do so
21:25:50 <cscott> TimStarling: yes, to some extent.
21:26:03 <cscott> it turns out that some of the nastier features of the current system aren't actually widely used
21:26:19 <brion> and at some point the old rule variants would cease to parse? or be turned into invisible? or?
21:26:26 <gwicke> I don't see a good reason to introduce new syntax now
21:26:39 <cscott> 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 <subbu> which effectively make them page-level rules.
21:27:43 <gwicke> 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 <gwicke> you'd still have to move them out
21:28:23 <sumanah> So, this is a super wide-ranging discussion and I'm calling time
21:28:24 <gwicke> but that can be a gradual process
21:28:35 <gwicke> I discussed some of that at https://www.mediawiki.org/wiki/Requests_for_comment/Page_and_category_based_language_variant_conversion
21:28:36 <subbu> and use the Parsoid-based linting system to flag problematic scenarios.
21:28:39 <cscott> TimStarling: yes -- but i'm concerned there are some template issues that need to be resolved.
21:29:09 <sumanah> 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 <cscott> 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 <cscott> provisionally we would like the answer to be "yes" and "no"
21:29:45 <sumanah> #agreed more discussion onlist
21:29:47 <sumanah> :)
21:29:56 <sumanah> #topic square bounding boxes
21:29:57 <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes
21:30:02 <sumanah> #info "The current mediawiki syntax for image thumbnails and resizing works poorly for images which are taller than they are wide."
21:30:10 <sumanah> #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 <sumanah> "
21:30:15 <gwicke> cscott, last time we discussed this it was 'yes' and 'no'
21:30:24 <sumanah> #info C. Scott would like for us to weigh four proposals for remedying this situation:
21:30:24 <sumanah> #info 1) Change mediawiki to use square bounding boxes by default (opt-out).
21:30:24 <sumanah> #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 <sumanah> #info 3) Add a new "upright=auto" option (minimalist, opt-in)
21:30:24 <sumanah> #info 4) Add a new "scale=N" option (adds new functionality, opt-in)
21:30:33 <cscott> gwicke: can templates use glossaries at all?
21:30:46 <gwicke> cscott, only the global ones associated with the page
21:30:48 <sumanah> #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 <gwicke> and once-only inline rules
21:31:13 <sumanah> bawolff: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140402.txt has the logs up till now
21:31:13 <cscott> 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 <bawolff> Thanks
21:31:44 <sumanah> jorm: maybe you have an opinion on this? (the bounding boxes)
21:31:45 <brion> don’t we already support square bounding boxes?
21:31:48 <brion> [[file:foo|300x300px]]
21:31:55 <cscott> we don't support square bounding boxes for thumbnails of default size
21:32:06 <brion> shouldn’t that simply be a change to the default behavior?
21:32:23 <cscott> brion: that's one of the proposals in the rfc, yes.
21:32:26 <gwicke> that's my preference too
21:32:37 <cscott> proposal #1, in fact.
21:32:42 * bawolff doesnt actually see what the problem is
21:32:46 <brion> furthermore, do we really mean *square*?
21:32:53 <brion> or do we mean “something with a defined maximum height”?
21:33:03 <brion> eg 220x180 or whatever
21:33:03 <cscott> brion: yes. we mean, we limit width or height, *whichever is larger*
21:33:04 <gwicke> 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 <brion> TimStarling: how so?
21:33:32 <gwicke> TimStarling, existing content would need to be adapted
21:33:42 <gwicke> but that's fairly easy to automate
21:33:43 <cscott> TimStarling: somewhat less than that, as it would only affect non-landscape images, and there are not that many of those
21:33:50 <gwicke> the more interesting cases are in templates
21:34:08 <gwicke> we'd need to investigate whether a width-only restriction is still needed there
21:34:15 <cscott> certainly not very many non-landscape images which aren't already using explicit sizes
21:34:18 <gwicke> 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 <gwicke> TimStarling, it's fairly easy to keep current sizes
21:35:03 <cscott> TimStarling: parse page, for every image fetch imageinfo, if imageinfo says non-landscape, tweak image options to preserve current size.
21:35:04 <TimStarling> [[File:foo.jpg|thumb]] 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 [[File:foo.jpg|thumb|200px]] have a square bounding box
21:35:30 <gwicke> what we discussed so far was to have an optional scale factor
21:35:43 <gwicke> that can be used to change the relative bbox size similar to upright
21:35:48 <brion> 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 <cscott> I could be on-board with "proposal 1a", "only change [[File:foo.jpg|thumb]] to have a square bounding box"
21:36:15 <cscott> that's the simplest possible thing that would help
21:36:29 <brion> i’m happy to break layout in this way, it doesn’t bother me offhand
21:36:34 <cscott> gwicke: that's proposal #4, right?
21:36:52 <gwicke> cscott, is #4 default square too?
21:37:06 <cscott> 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 <gwicke> so without scale the bbox is not square?
21:37:32 <cscott> gwicke: that's my understanding of the proposal
21:37:34 <gwicke> that would run into the inconsistency issues we discussed before
21:38:01 <cscott> gwicke: feel free to suggest a variant. proposal #4 was supposed to match your proposal, perhaps i misunderstood it.
21:38:04 <gwicke> that's why I proposed to move to square by default with the optional scale parameter
21:38:37 <cscott> gwicke: i don't understand. can you elaborate?
21:38:52 <brion> i’m not sure i understand the scale factor
21:38:52 <gwicke> option 1 and 4 combined
21:39:19 <gwicke> the scale factor works basically like upright
21:39:28 <mooeypoo> 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 <gwicke> it scales relative to the default size
21:39:52 <brion> the default size when not thumbnailed is hard to predict
21:40:02 <gwicke> the problem with #4 is that adding scale now also magically changes the bbox from width-only to square
21:40:02 <brion> since it can change if the image is rescaled and reuploaded
21:40:24 <bawolff> Default size as in user option, or default as in natural unscaled size
21:40:27 <bawolff> ?
21:40:45 <brion> which might be thousands of pixels, for the latter
21:40:52 <gwicke> only for scaled versions
21:41:20 <gwicke> there is a related discussion about more semantic image types
21:41:20 <cscott> TimStarling: the problem with proposal "1b" is that it will make 'upright' even more unusual.
21:41:20 <gwicke> beyond thumb
21:41:29 <gwicke> scale could apply to those too, or those semantic classes could actually replace scale
21:42:07 <robla> 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 <cscott> 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 <gwicke> I like the idea of moving towards more semantic image types, but am sceptical about some uses cases in templates
21:42:44 <gwicke> robla, our output can have nice semantics already
21:42:47 <jorm> wait, whut? bounding boxes?
21:42:50 <gwicke> the problem is that we have to abuse upright
21:43:09 <gwicke> when images are re-uploaded, the image size can change drastically
21:43:37 <bawolff> So what is the problem this is trying to solve?
21:43:46 <gwicke> 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 <cscott> 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 <cscott> 'upright' should be thrown from a bridge.
21:44:59 <mooeypoo> :D
21:45:02 <gwicke> also many new images are no longer 3:4 aspect ratio
21:45:02 <cscott> by which i mean, "deprecated". but that's offtopic.
21:45:21 <brion> so fundamental question:
21:45:29 <brion> why is a square bounding box being promised when it’s not delivered?
21:45:34 <cscott> 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 [[File:Foo.jpg|thumb]] means "make it whatever smallish size the user wants"
21:46:02 <cscott> if you manually compute the aspect ratio of your image, you can set "upright=<aspect ratio>" to get a consistent square size
21:46:18 <gwicke> 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 <cscott> 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 <gwicke> 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 [[File:Foo.jpg|thumb|200px]] 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 <cscott> 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 <cscott> if you specify a width of 199, it's 199
21:48:00 <AaronSchulz> ?
21:48:01 <TimStarling> yes
21:48:12 <cscott> 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 <cscott> because it rounds to the nearest 10px
21:48:21 <cscott> *rounds the width
21:48:23 <gwicke> we are mostly talking about thumb & upright
21:48:23 <brion> at this point i’m very confused and still don’t understand the fundamental problem being solved by this rfc
21:48:37 <gwicke> parsoid alway emits square bounding boxes for non-upright images
21:48:42 <gwicke> so 200x200px
21:48:44 * AaronSchulz sits at brion's camp fire
21:48:44 <bawolff> Does anyone actually use upright in the wild
21:48:48 <cscott> 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 <bawolff> because ive never seen it used
21:49:08 <cscott> 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 <bawolff> and it seems poorly thought out
21:49:32 <gwicke> bawolff, we see it quite often
21:49:38 <cscott> bawolff: it is, unfortunately, very common in some wikis.
21:49:42 <sumanah> I feel like I need diagrams to understand the current situation and what we might want instead
21:49:48 <cscott> gwicke: doesn't {{Largethumb}} use it?
21:49:57 <TimStarling> cscott: yes
21:50:00 <bawolff> cscott: ok. Just checking
21:50:11 <gwicke> afaik largethumb actually sets a px size
21:50:19 <cscott> gwicke: well, that's good ;)
21:50:32 <gwicke> https://nl.wikipedia.org/wiki/Sjabloon:Largethumb
21:50:35 <gwicke> 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 <subbu> bawolff, frwiki uses upright a lot from waht i udnerstand
21:50:51 <cscott> 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 <mooeypoo> cscott, upright has rounding to the nearest multiple of 10px.
21:51:13 <cscott> mooeypoo: yes
21:51:38 <gwicke> TimStarling, we are mostly concerned about images without px sizes
21:51:48 <gwicke> so either bare thumb or thumb + upright
21:51:48 <cscott> 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 <cscott> fwiw
21:52:10 <TimStarling> cscott: let it be ugly
21:52:22 <brion> gwicke: so if theres’s not a known size, don’t emit one?
21:52:29 <brion> is that a feasible option?
21:52:47 <cscott> 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 <bawolff> Making bare thumb take both dimensions into account sounds sensible to me personally
21:52:58 <cscott> my personal preference was proposal #2, but nobody but me likes that one. ;)
21:53:04 <gwicke> 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 <cscott> MatmaRex: it matches what users actually want to do, and it avoids forward-propagating the evil tarpit of wikitext image options.
21:54:00 <brion> 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 <brion> which is to say, it’s not parsoid’s problem
21:54:07 <MatmaRex> hmmm. ooookay.
21:54:36 <sumanah> OK, we have like 5 more min here. Any conclusions?
21:54:48 <mooeypoo> brion, i think the current issue is that the default wiki size outputs width-only restriction, not a bounding box?
21:54:56 <cscott> it seems like if i change the default behavior of bare 'thumb' that might have a chance to get merged
21:55:07 <brion> mooeypoo: the default wiki size is the natural size of the image if nothing is specified
21:55:11 <gwicke> 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 <cscott> 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 <brion> 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 <mooeypoo> brion, aye, but in thumbnails, it's a specific width given by default and overridden in wiki wgUserOptions[thumbsize] IIRC
21:55:54 <brion> 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 <cscott> TimStarling: I can answer that question, but not online.
21:56:09 <gwicke> 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 <brion> 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 <cscott> 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 <gwicke> brion, we opted to make life for VE and other editors easy by giving them an easy square bounding box model
21:57:46 <cscott> 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 <brion> gwicke: if the bounding box were removed, what would be the result?
21:57:54 <gwicke> so it's our task to deal with the impedance mismatch
21:58:03 <cscott> ok. i have to turn into a pumpkin soon, my kid needs to be picked up from daycare.
21:58:08 <sumanah> So the answer to "any conclusions?" sounds like "nothing that can be snappily articulated" :)
21:58:17 <subbu> :)
21:58:25 <cscott> 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 <sumanah> do we want to have cscott do those 2 patches, get more input onlist & onwiki and return to this next week?
21:58:42 <brion> imo ‘upright’ should behave as ‘thumb’ with the width and height switched
21:58:48 <brion> 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 <gwicke> 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 <cscott> brion: that matches how it was originally documented, but *not* how it was actually implemented.
21:59:07 <brion> 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 <gwicke> brion, you mean don't support resizing thumbs?
21:59:35 <sumanah> #info pixel sizes, 'upright', strange conversions, and other issues occasion much comment and confusion
21:59:40 <brion> gwicke: i mean leave default-size images at whatever the default is going to be
21:59:44 <bawolff> Brion: so upright becomes the equiv of putting an x in front of the size
21:59:45 <brion> and not enforce it at the editor level
21:59:53 <sumanah> we gotta go, all
21:59:54 <gwicke> brion, that's what we are already doing
21:59:55 <cscott> #action cscott to patch upright to have a square bounding box, and use dumpGrepper to see whether this breaks too much
21:59:58 <sumanah> let's talk more onlist/onwiki
22:00:02 <brion> then i’m super confused wheret he boxes come from :D
22:00:04 <sumanah> #endmeeting
<gwicke> brion, it's tricky ;)
<cscott> sumanah: thanks
<brion> hehe
* subbu is glad i am not th eonly one confused
<brion> ok i’ll have to fiddle around and do some more research on this
<brion> i gotta brush up on VE and parsoid anyway :D
<cscott> bawolff: yes, but upright also takes a scale factor. for no good reason.
<sumanah> oh is this sort of thing Brion bait? :)
<brion> :D
<sumanah> let's let cscott pick his kid up :)
<sumanah> thanks all
<gwicke> for all you wondering, here is our DOM spec documenting all this: https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images
* cscott has to run, kid is waiting
<brion> yep
<brion> thanks everybody for participating!
<cscott> gwicke: although i haven't updated that with the new hotness yet
<cscott> thanks for suffering through languageconverter everyone, and for helping reach some sort of plan for thumb/upright.
<brion> ok i gotta run, be back on regular channels in a bit
* brion has quit (Quit: brion)
<cscott> i'll check backlog when i return, in case you've got any lingering qs
<gwicke> cscott, we'll need data on how many images would change dimensions
<gwicke> and possibly a strategy to update them
|