[16:56:39] Language Engineering office hour starts here in a few minutes [17:00:10] Hello [17:00:14] #startmeeting Language Engineering monthly office hour - May 2014 [17:00:14] Meeting started Wed May 21 17:00:14 2014 UTC and is due to finish in 60 minutes. The chair is arrbee. Information about MeetBot at http://wiki.debian.org/MeetBot. [17:00:14] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [17:00:14] The meeting name has been set to 'language_engineering_monthly_office_hour___may_2014' [17:00:28] Hello, Welcome to the monthly office hour of the Wikimedia Language Engineering team [17:00:34] Hi santhosh [17:00:50] Hi arrbee [17:01:11] My name is Runa. I am the Outreach co-ordinator for our team and will be hosting the session today [17:01:35] Our office hours are held every 2nd Wednesday of the month [17:01:53] We delayed it by a week this month as we were traveling [17:02:28] Before we go further here is an important message: [17:02:52] The chat today will be logged and publicly posted. It is also mentioned in the channel topic (above). [17:03:25] Our last office hour was held on April 9, 2014. The logs are at: [17:03:31] #link https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2014-04-09 [17:04:06] aharoni kart_ divec Nikerabbit pginer santhosh are here today and will be answering questions [17:04:47] In today's session we would like to talk about our recent work and end with an open session for Q & A [17:05:37] сәлем [17:05:57] The Wikimedia Foundation's Language Engineering team builds language features and tools to support our wiki communities across the world [17:06:18] We are a distributed team and operate from various locations around the globe [17:06:56] As already mentioned in the mail I sent out earlier, we have been concentrating on the Content Translation tool and intend to make the first release very soon [17:07:27] We have mentioned the Content Translation project several times in our earlier office hours but we will talk more about it today [17:07:57] The Content Translation tool is a way to create new Wikipedia articles from existing articles in another language [17:08:05] Hi alolita [17:08:45] The tool is designed to have an editing interface and several translation aids like dictionaries, and machine translation support [17:09:12] Hi Runa [17:09:22] The purpose of the tool is to help create an initial version of an article which can then be published and edited like any other article [17:09:48] The immediate benefits from this tool are: [17:10:19] 1. the relative ease in quick article creation for both new and advanced users [17:10:46] 2. provide assistance to achieve high quality translations [17:10:47] and [17:10:57] 3. prevent errors [17:11:16] Development on this tool started in February, earlier this year [17:11:51] The initial phase of development was focused primarily on research and exploration of backend design choices [17:12:50] Over the past month we have narrowed down on the actual deliverables for the first release and the development plan to support this release [17:13:43] We do not have a specific release date just yet but are aiming for sometime in the next couple of months when we will be able to present this as a beta feature [17:14:36] Presently we are fully absorbed in development of key features for the first release (termed as "minimum viable product" or "MVP" in product speak) [17:15:04] (There was an interesting discussion about MVP in the ECT meeting yesterday) :) [17:15:40] Alongside we are collaborating with other teams on machine translation support, analytics and performance [17:16:03] Detailed designs are at: [17:16:12] #link https://commons.wikimedia.org/wiki/File:Content-translation-designs.pdf [17:16:32] The workflow we are creating will be: [17:17:00] 1. Show a red link in the interlanguage area for a missing language version of the displayed article [17:17:42] 2. Clicking the red link would display the Content Translation editor (for logged-in users only) and users can choose to translate the article or create it from scratch [17:18:18] 3. The editor displays 3 columns - source article text, target article text, tools column for the translation aids [17:18:40] 4. Translations are done in the editor by the logged-in user [17:19:28] 5. Using a publish button from the editor, a new version of the article in the target language is published under the user's namespace on the target language wiki [17:19:56] ^^ workflow is only for the first release i.e. MVP [17:20:41] We went for a simple REST style api that can easily be cached by Varnish [17:21:46] We are using a special presentation of the rich markup called LinearDoc to enable transfer of markup like bolds and links even if the word order is different in machine translation [17:22:25] We use the Parsoid service to get the translatable content in HTML, then we segment it and when saving we use Parsoid to convert it back to wikitext [17:22:43] divec: santhosh : would you like to add anything more about this? [17:23:44] https://www.mediawiki.org/wiki/Content_translation/Documentation has most of these technical details [17:25:00] Thanks santhosh [17:25:06] that's helpful santhosh [17:25:29] (writing the link again in a bot-friendly way) [17:25:32] #link https://www.mediawiki.org/wiki/Content_translation/Documentation [17:25:55] As we go closer to the release date, we will step up on the communications [17:26:21] Until then the best place to track the project is: [17:26:27] Does this tool ties with Wikidata? [17:26:31] #link https://www.mediawiki.org/wiki/Content_translation [17:26:45] Hi Pavanaja [17:26:51] Pavanaja: we intend to do so [17:26:52] Pavanaja: yes [17:26:54] Hi Alolita [17:27:29] Pavanaja: the plan is to release basic wikidata integration in the first deployment [17:27:33] Is this something lik a Translation Memory (TM) tool? [17:28:09] it will use wikidata to check whether it's possible to insert links to the target article in the target wiki automatically. [17:28:55] You could view the tool in action here: [17:28:58] so, for example, if you are translating from English to Telugu, and the English article has a link to [[Philosophy]], and there is an corresponding article in Telugu, then the link to the Telugu article will be automatically inserted into the translation [17:29:05] #link http://language-stage.wmflabs.org/w/index.php?title=Special:ContentTranslation&page=Food&lang=es [17:29:16] (you need to login) [17:29:38] interlanguage links are stored in Wikidata, so this is a kind of Wikidata integration. [17:29:55] future development may have deeper Wikidata integration. [17:30:38] about Tranlsation Memory, this is not a translation memory tool; it is a translation tool that will include translation memory as one of its features. [17:31:08] Thanks aharoni for that neat summary [17:31:34] The development roadmap and timeline of milestone completion can be found at: [17:31:42] #link https://www.mediawiki.org/wiki/Content_translation/Roadmap [17:32:04] (This page is changing very rapidly though) [17:32:18] More questions? [17:35:36] just a little announcement [17:36:41] the "compact interlanguage links list" is currently broken in production because a of an incompatible core change [17:36:49] Oh. [17:37:02] I couldn´t figure out what broke it. [17:37:27] a core change in how the sidebar is handled in the Vector skin. [17:37:30] I already committed a fix, but it needs review and deployment. [17:37:43] https://gerrit.wikimedia.org/r/#/c/134592/ [17:37:55] Thanks aharoni. [17:38:13] (leaving as "aharoni", staying as "aharoni|mobile") [17:39:20] Just in case there is some interest about the technical architecture of the Content Translation tool, you can find it here: [17:39:24] #link https://www.mediawiki.org/wiki/Content_translation/Technical_Architecture [17:39:47] Pavanaja, any more questions? [17:41:49] Okay… if there are no more questions we can wrap up early :) [17:42:38] I am waiting for the tool [17:42:49] #info Our next office hour is scheduled for 11 June 2014 [17:43:01] Great to hear [17:43:23] Pavanaja: we will make sure to communicate about its arrival much in advance [17:43:35] Thanks RB [17:43:49] Meanwhile if you like you can look at the staging instance and give us feedback [17:43:58] :) [17:44:08] We are starting small, but we have further plans [17:44:47] Our mailing list is mediawiki-i18n@lists.wikimedia.org and IRC channel is #mediawiki-i18n [17:45:07] Like a "translation center", which will show suggestions for translation, [17:45:10] We will be around on #mediawiki-i18n [17:45:35] Statistics, management of existing translations, etc. [17:46:00] And more wikidata integration. [17:47:09] But for a start - a simple translation interface with basic tools. [17:50:40] Thanks aharoni|mobile [17:50:53] Thanks everyone for joining [17:51:13] The office hour ends here today (a tad bit early than usual) [17:51:29] The logs will be on meta very soon: [17:51:34] #link https://meta.wikimedia.org/wiki/IRC_office_hours [17:51:44] #endmeeting [17:51:45] Meeting ended Wed May 21 17:51:44 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [17:51:45] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-21-17.00.html [17:51:45] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-21-17.00.txt [17:51:45] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-21-17.00.wiki [17:51:45] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-05-21-17.00.log.html [17:51:46] thanks! bye [20:50:59] in 10 min in this room, we're talking about the square bounding box proposal + the typesafe enums proposal [20:51:31] https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-21 [20:59:44] ok, AndyRussG & cscott - almost ready? :-) [20:59:58] all set here :) [21:00:01] #startmeeting Discussion of square bounding boxes and typesafe enums| Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours [21:00:01] Meeting started Wed May 21 21:00:00 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:01] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:01] The meeting name has been set to 'discussion_of_square_bounding_boxes_and_typesafe_enums__channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' [21:00:05] #chair sumanah brion Tim-away [21:00:05] Current chairs: Tim-away brion sumanah [21:00:10] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-21 [21:00:19] First, cscott :-) [21:00:23] since yours should be faster [21:00:31] #topic square bounding boxes [21:00:39] #link https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes [21:00:42] This should be quick [21:00:45] #link https://gerrit.wikimedia.org/r/#/c/123683/ cscott is looking to get this merged :-) [21:01:03] is that right C. Scott? [21:02:04] #chair sumanah brion TimStarling [21:02:04] Current chairs: Tim-away TimStarling brion sumanah [21:02:14] * brion double-checks the code [21:03:07] cscott: so as i understand this only affects the default case where something’s specified as a thumb without a size spec? [21:03:23] and sets a max height to match with the default thumb width [21:04:05] i’m pretty happy with that i think [21:04:06] TimStarling: ? [21:04:47] I gave it +2 already, but then cscott changed the code substantially and I haven't gotten around to reviewing it again [21:05:04] if it looks good to you, just give it +2 [21:06:13] ok i’ve done so [21:06:18] let’s make sure it runs its tests and whatnot :) [21:06:28] Sweet [21:06:42] #agreed to +2 https://gerrit.wikimedia.org/r/#/c/123683/ [21:06:52] rock, we can move on I think. [21:06:56] #topic typesafe enums [21:07:00] #link https://www.mediawiki.org/wiki/Requests_for_comment/Typesafe_enums [21:07:04] #info Andrew Russell Green calls this "a facility that I've found really useful so far, and is used in other stuff that we'd like to propose moving to core :)" [21:07:23] #info AndyRussG today seeks "I guess a general path forward for any changes required to merge this to core, or an opinion on the feasability threof" [21:07:31] ok so i think typesafe enums are cute and sometimes nice, but i don’t have a strong opinion [21:07:31] it looks slow [21:07:32] #info Andrew says: "I'm sure there are improvements to be made (for example, see MWalker's suggestions on the talk page), so if we can consider what would need to be done, and end up with something really nice that improves MW code quality, I think that'd be fantastic" [21:07:33] sorry i'm late, what did i miss? ;) [21:07:38] all of my rfc! [21:07:42] cscott: brion merged your change [21:07:43] yes! [21:07:45] :D [21:07:51] and then jenkins bot rejected.. [21:08:00] <^d> As I said on the list, I'm not a fan of enums. I don't make use of them in languages that have them natively, and implementing them in userspace seems slow per Tim. [21:08:04] probably because the release notes conflicted [21:08:06] quick, rebase before he changes his mind again [21:08:09] #link http://lists.wikimedia.org/pipermail/wikitech-l/2014-May/076605.html - there have been some questions/discussion on the mailing list by hashar & ^d & others [21:08:27] James_F thinks i should push to get this in 1.23 [21:08:35] so there’s a few different kinds of enums in the universe i think [21:08:37] but maybe we can return to discuss this after typesafe enums [21:08:44] one is ‘i really just need names for a couple flags’ [21:08:44] cscott: yeah, sounds good to me. [21:08:57] one is ‘i need user-friendly markers for id numbers that go in some API or database’ [21:09:00] also, https://gerrit.wikimedia.org/r/#/c/133600/ is the more contentious part of this, i'd like to discuss that as well [21:09:03] Personally I'm not a fan of the syntax of having a $ in DayOfTheWeek::$TUESDAY (I know that's really superficial) [21:09:06] in HHVM, class constants are probably very heavily optimised [21:09:07] and another is ‘i need a code-only marker for various extensible enum list' [21:09:10] * cscott will shut up while we discuss enums [21:09:22] since the JIT knows what the value of the class constant is when it is generating machine code [21:09:28] so it probably just uses the immediate value [21:09:56] so I don't think the "$" is superficial, it makes it a hashtable lookup instead of an immediate machine code operand [21:10:11] Hmmmm :) [21:10:21] do we tend to use enums in perf-critical code paths? [21:10:25] (i’m thinking parser/sanitizer) [21:10:44] Also note that in this implementation nothing happens if the class isn't loaded [21:10:44] i guess one question is: are we moving to enums for better readability of infrequently used code, or are we moving to enums because we want blazing fast performance on the hot paths through our codebase [21:10:54] I meant superficial from an aesthetic point of view [21:10:57] because the SplEnum implementation is almost certainly faster. but not better for readability. [21:11:16] (although it would be nice to get benchmarks to verify my intuitions) [21:11:34] <^d> SplEnum requires people installing a non-default pecl extension as bawolff pointed out on-list. [21:11:34] Re: peformance I do think it'd be a matter of a tradeoff, and some benchmarking would be cool [21:11:35] i don't remember seeing wide-spread enums in the parser [21:11:39] <^d> That's a -1 from my POV for it. [21:11:58] ^d: I didn't point that out, but I agree I don't like that :) [21:11:58] AndyRussG: https://www.mediawiki.org/wiki/Performance_profiling_for_Wikimedia_code might help you do a bit of benchmarking. Maybe. [21:12:15] well, a standalone microbenchmark would be my first pass [21:12:26] just to get a rough order of magnitude for the different enums [21:12:40] also, a standalone microbenchmark would probably be easier to run on HHVM [21:12:41] <^d> bawolff: Sorry, Tyler, not you. [21:12:47] a common usecase for enums is in function argument -- instead of having a bare TRUE / FALSE / NULL you have some explicit type [21:12:49] Definitely ... Still if it's a trade-off between an extremely small performance difference and better and typesafe code, I'd take the latter [21:13:11] <^d> mwalker: Well if you're passing boolean params to a function you're breaking coding conventions anyway :) [21:13:12] For me the ability to to typehint is really nice [21:13:49] The issue I have with SplEnum is it works quite differently from enums in other languages and is extra verbose [21:13:59] #info http://www.php.net/manual/en/class.splenum.php [21:14:31] I think Antoine may be the only one arguing for SplEnum, but I could be mistaken. Anyone arguing for it here? [21:14:41] not i, i don’t like splenum much [21:14:43] <^d> I don't think anyone's arguing for it. [21:14:53] Cool [21:14:55] <^d> I think Antoine was just like "hey maybe this?" not so much a strong advocate. [21:15:05] so i think there are two questions [21:15:14] one is: do we want to use this sort of facility widely? [21:15:24] the other is: when folks do want to use it, should they use a common base class from core? [21:15:31] -or implement separately in every ext? [21:15:35] nope, i like the new code. but i'd like to get a little bit of insight into performance. [21:15:45] so that we know whether to recommend it for hot paths or not [21:16:00] gwiw, Parser->mOutputType is an enumerated type, but it's not on a hot path [21:16:44] Parser::setFunctionHook takes an enumeration too, again now performance-sensitive [21:16:49] __toString() should probably be included in the benchmark [21:17:04] I can do benchmarks and add them to the RFC [21:17:05] since that suggested case syntax will call it [21:17:20] <^d> brion: We'd have to ask more people if they want to use it widely. [21:18:15] I think that most places where you use a class constant you could use something like this [21:18:44] SplEnum is PECL? [21:18:47] so iiuc, basically proposal is to copy https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FCampaigns.git/e4714059330ace2c9c8457433919fb90ce1f4af5/includes%2FTypesafeEnum.php into core so people could use it [21:18:54] that kind of rules that out doesn't it? [21:19:19] $ php maintenance/eval.php [21:19:19] > return class_exists('SplEnum'); [21:19:20] bool(false) [21:19:27] <^d> TimStarling: Yes. [21:19:29] yeah let’s kill SplEnum it’s not there by default [21:19:32] I think we could also add what mwalker suggests on the talk page, about setting a constant integer value for database, and some facilities for bitmask when desired [21:19:50] quick side question: do you plan to discuss square bounding boxes for upright as well in this meeting? [21:20:26] <^d> Already done. [21:20:29] <^d> brion merged. [21:20:40] gwicke: oh i think we forgot about that case — it might make sense to turn uprights into squares if the current patch doesn’t do that [21:20:44] not for upright, just for default params [21:20:51] gwicke: We're returning to the topic after the enums chat because there's more to discuss, now that cscott is around. [21:20:52] <^d> Oh nvm, ignore me. [21:21:41] it's ok! we were done until we were not :) [21:22:36] re: the enums, I looked through a few other folks' implementations, seemed a lot of people are doing something similar, though I imagine it's not enough code to make worrying about an external library worth the effort [21:22:54] it probably won't be a hashtable lookup in HHVM, btw, I think it will just be dereferencing and Variant unboxing [21:22:56] square bounding boxes now? [21:22:59] brion, TimStarling, sumanah: thx [21:23:05] i thought i could fix the rebase conflict before we got back to me [21:23:15] but i'm multitasking poorly [21:23:27] are we done with the enums topic? can we have a couple #agreed or #action lines? [21:23:49] #agreed not gonna use SplEnum - it’s not available by default [21:24:10] i think we’re still kinda undecided on whether to put TypesafeENums class into core [21:24:20] and even more undecided on whether to change any code to use it [21:24:22] Is doing some benchmarks #agree-able? [21:24:31] sounds good. TimStarling ? [21:24:50] #action AndyRussG to benchmark setup and access performance [21:25:00] cool! :) [21:25:03] * TimStarling likes #action [21:25:08] \o/ [21:25:12] sweet [21:25:25] ok, we can therefore move on to [21:25:25] mwalker: you mentioned some other use cases before? should we look at those? [21:25:25] #topic square bounding boxes redux [21:25:26] from what TimStarling was saying earlier, HHVM benchmarks are also desirable? [21:26:03] well; if we dont want to use this for performance critical code then it doesn't make much sense [21:26:12] but I had suggested use cases of namespaces and permissions [21:26:32] MartijnH: I can also try HHVM benchmarks [21:26:35] #info also, https://gerrit.wikimedia.org/r/#/c/133600/ is the more contentious part of this, i'd like to discuss that as well [21:27:01] hhvm is pretty easy, now that they have packages on hhvm.com [21:27:18] Ah cool plums [21:27:22] just run "hhvm -f benchmark.php" instead of "php benchmark.php" [21:27:47] or "hhvm -v Eval.Jit=true -f benchmark.php" to be sure the JIT is enabled [21:27:48] sigh rebasing fail, i managed to add https://gerrit.wikimedia.org/r/#/c/134734/, boo me [21:28:06] so I'm not convinced that upright has much of a use case left with square bounding boxes [21:28:29] TimStarling: thanks [21:28:30] the only use case would be resizing images relative to a user's default thumb size preference [21:29:18] hmm [21:29:19] which might be better covered by introducing more semantic alternate image types [21:29:26] you know this change that cscott is merging... [21:29:36] will that make the site go down when it is deployed? [21:29:42] what? [21:29:44] * TimStarling always thinks of these things too late [21:30:05] well, how many thumbnails do you suppose will be regenerated? [21:30:11] mwalker: (aside: still enumish: got more details, maybe to put on the talk page or send elsewhere? thanks btw) [21:30:42] TimStarling: the non-square ones, i guess. [21:30:44] better make sure Greg and Sam know about it I guess [21:30:49] we could probably pre-generate them. [21:30:57] i could give you exact statistics [21:31:17] i have a db of all figure usage on en/fr/it/de/.. wikis [21:31:31] the question is whether the image scalers or swift backend will fall over when it is deployed to en or commons, due to increased rate of scaling operations [21:32:28] ok, patches are rebased, so i can devote brain cells to discussion [21:32:41] i think it would be a good idea to pre-scale as many images as possible [21:33:02] i can generate a list of all images on enwiki (say) that would change size as well as the new size [21:33:25] you think it won't be too difficult to generate that list? [21:33:25] i should just be able to ask mw for those thumbs in the new size to seed them in swift [21:33:25] no, less than an hour [21:33:27] ^d: is mwgrep on the expanded text or the source text? [21:33:29] ok, sounds good then [21:33:31] it's a good segue to the *next* topic [21:33:48] <^d> AaronSchulz: Expanded. We don't store unparsed wikitext. [21:34:04] <^d> (yet. maybe?) [21:34:12] since i wrote that code/assembled that db in order to show that https://gerrit.wikimedia.org/r/133600 would be safe [21:34:25] see https://bugzilla.wikimedia.org/show_bug.cgi?id=63904 for a link to the code, and statistics [21:34:33] that part of the patch affects far fewer images [21:35:49] I gave my opinion on that earlier in this meeting [21:35:54] swift stuff lasts forever, right? so i can start requesting the new sizes for the thumbnails now, regardless of the deployment/merge time of the patch. [21:36:28] yes [21:36:34] let's sync up -- so are we still talking about 'thumbs with no explicit size should use a square bounding box (that's https://gerrit.wikimedia.org/r/123683) [21:36:41] let's finish up that part [21:36:49] the patch has been rebased [21:37:17] my understanding is that someone will +2 it, and i will asap start a process to start requesting thumbs that change size, so that changeover will not be drastic [21:37:41] and someone (?) will inform greg and sam, so we all know what's going on before the code goes live? [21:37:47] last meeting we had "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)" [21:38:09] TimStarling: that's the next part. i'm just trying to make sure we're all on the same page regarding the first part. [21:38:12] before we move on [21:38:51] first part being "thumbs with no explicit size" (upright flag semantics unchanged) [21:39:21] ok? my summary above is correct for the first part? [21:39:41] sumanah: you want to add some # actions? [21:39:51] greg-g: for changes that need to be deployed carefully, I'm meant to add you as a reviewer, right? [21:40:28] I think we pretty much agree that with the right preparations the move to square bounding boxes for bare thumbs is a good idea [21:40:46] TimStarling: that's good yeah, what are you thinking of? [21:40:50] ie: how carefully? :) [21:41:21] TimStarling: ah, I see in -dev [21:41:27] load on swift and image scalers needs to be watched, since thumbnailing parameters will change [21:41:30] well, at a minimum you should probably check with me to ensure that my job to pregenerate the new image thumbs has completed? [21:41:39] be vewy vewy quite [21:41:56] quiet [21:41:58] if there is an overload, it should be rolled back [21:42:09] gotcha [21:42:35] cscott: can we chat post this discussion re deploy details? [21:42:36] other than me writing a script to try to pregenerate images, is there any other possible deployment strategy to mitigate? [21:43:01] * sumanah wants to leave #action items to others to decide [21:43:11] greg-g: sure. [21:43:52] and maybe it should be flagged in the release notes more prominently that this will have affect on scaler load? [21:44:04] cscott: sounds good [21:44:14] #action https://gerrit.wikimedia.org/r/123683 expected to be +2'd [21:44:30] #action cscott will work with greg-g to ensure no deployment hiccups [21:44:40] #action cscott will write a script to pre-generate thumbnails that will change size, to avoid scaler load [21:45:19] ok, are we done with that then? [21:45:52] I believe so [21:45:54] now we can start the screaming and yelling ;) [21:46:00] let's move on [21:46:06] so the second part makes 'upright' simultaneously more and less useful [21:46:22] https://gerrit.wikimedia.org/r/#/c/133600/ and https://bugzilla.wikimedia.org/63904 for those following along at home [21:46:31] it makes 'upright' also use a square bounding box. [21:46:49] so that it actually is useful for upright images, and doesn't require the user to manually specify the aspect ratio of the image [21:47:17] Something like 0.75% of the images on enwiki use the 'upright' flag [21:47:26] this would change the size of 0.04% of the images [21:47:42] it'd be a mis-named 'scale' option, which scales relative to the user / wikis's default thumb size pref [21:47:55] since the number of images whose size changes is so small, it is proposed to reset the scale factor to 1.0 at the same time, which makes upright's semantics much less mysterious [21:48:19] (changing the default scale changes about 110 image references on enwiki) [21:48:57] yes, the semantics of upright would be pretty much "scale", and one might consider in the future adding an alias. but i'd rather upright go away entirely the the future. ;) [21:48:58] cscott, how many on frwiki use that flag? [21:49:09] it's in the bugzilla [21:49:28] because i remember reading on ve-feedback page that upright is popular/encouraged on frwiki [21:49:49] 17,870 of 1,242,985 images use 'upright' and the proposed change would alter the size of 1049 or 1053 of them. (the latter if the scale factor was changed to 1.0) [21:50:08] on frwiki [21:50:42] for dewiki, it's 38,624 of 1,786,779 and the size would be altered for 1963/1764 [21:50:52] while i'm copying numbers into chat ;) [21:51:06] can anyone explain to me why upright isn't the stupidest thing ever? [21:51:09] so deploying this one should be a breeze, at least. ;) [21:51:17] :) [21:51:23] TimStarling, that'd be hard [21:51:30] TimStarling: i think both gwicke and i agree that upright is stupid. [21:51:44] who approved it? [21:51:49] this patch makes it slightly less stupid. at least it has some sensible semantics (scales the default thumbnail size) [21:52:11] instead of being some completely weird thing that i don't want to write a bunch of special-case code for in parsoid [21:52:19] to me the interesting bit is that there are very few uses of the scale factor [21:52:26] (actually, that i've already written a bunch of special-case code for in parsoid, multiple times) [21:52:32] the help says "When the height of an image in thumbnail is bigger than its width (i.e. in portrait orientation rather than landscape) and you find it too large, you may try the option upright=N, where N is the image's aspect ratio (its width divided by its height, defaulting to 0.75)." [21:52:39] most non-scale factor uses will basically be made unnecessary by square bounding boxes by default [21:52:50] gwicke, no i think you are misinterpreting the statistics [21:53:10] if you do that, calculate the aspect ratio and use that as the upright factor, that is equivalent to a square bounding box, correct? [21:53:40] cscott, you don't break out the explicit factors vs. those using the default [21:53:54] but in my experience the explicit factor is very rare [21:54:15] but without an explicit factor, upright is just equivalent to multiplying the width by 0.75 [21:54:28] i think the ones which change size when the default scale factor is tweaked are the ones without an explicit scale factor. [21:54:28] that's like 110 images on enwiki. [21:54:28] so i think most upright images do actually have a scale factor. [21:54:28] i can crunch the exact numbers for you if you like. [21:54:28] TimStarling: i wrote that help text, i think. [21:54:33] the previous help text was much less helpful, and stated behavior that differed from the implementation [21:55:01] TimStarling: yes. multiplying the width by 0.75 is useful if all your images are either 4:3 or 3:4 [21:55:18] so upright w/o a scale factor gives you 4:3 images that are 'the right size' next to the rest of your 3:4 images [21:55:29] are least that's my reverse-engineering of the logic [21:55:33] *at least [21:55:45] afaik the factor was added later [21:55:48] which also explains the weird name [21:56:30] cscott, so I think it would be good to have data on how common the scale is actually set explicitly [21:56:30] but images are typically not one of those two aspect ratios [21:56:43] anyway, i think this patch is worth merging, because it affects very few images, and at least gives us semantics for 'upright' that don't require the user to manually compute aspect ratios. [21:57:14] gwicke: i can compute that, but i'm curious why you want to know. [21:57:26] if there are few uses with explicit scale factors then I'd prefer to just deprecate upright [21:57:44] since it'll be much less useful [21:57:48] upright with a specified width seems kind of pointless [21:57:51] and mis-named as well [21:57:56] there are 37,185 uses of upright on enwiki [21:58:03] since you could just multiply the specified width by the scale factor and omit upright [21:58:05] we could deprecate it, but probably not without tool assistance [21:58:22] upright is ignored if there is a specified with. [21:58:24] *width [21:58:28] there are parser tests for that [21:58:33] right... [21:58:54] the original use case for upright will disappear with square bounding boxes [21:58:58] it's only use is scaling the "default size" of the thumbnail (which might be user-specified) [21:58:58] without a specified width -- at least it does something unique [21:59:34] (and by user specified i mean in the user's preferences, not in wikitext) [21:59:41] well, the question is whether people actually want square bounding boxes or if they want their images to be shrunk by some arbitrary factor [22:00:04] the rounding to the nearest 10px is pointless, right? [22:00:25] TimStarling: i think the real missing feature is a 'scale and crop' option that will give me an exactly XxYpx image if i ask for one, cropping the edges as needed. but that's a different patch set. [22:00:29] it doesn't actually reduce the number of generated images, like it claims [22:00:42] the 0.75 default combined with the then-common 3:4 aspect ratio suggests that they wanted the equivalent of square bounding boxes [22:00:49] it is probably pointless, yes. [22:01:38] gwicke: but square bounding boxes already existed [22:01:45] at least for specified widths [22:01:56] yeah, but not for a bare 'thumb' [22:02:18] if that's what they wanted, it would have been trivial to implement [22:02:27] remember that upright is only used if there are no explicit dimensions [22:02:28] since the user's preferred thumbnail size was variable, it was formerly impossible to get "a square bounding box of the user's preferred thumbnail size" [22:02:32]