[Wikitech-l] Wikimedia Phabricator down: Dec 18th 00:00-08:00 UTC
Due to migrating most of RT to Phabricator, phabricator.wikimedia.org will be down and NOT AVAILABLE for eight hours starting on Thursday 18 December 00:00 UTC (that is Wed 17 Dec 16:00PST for people in San Francisco). In those eight hours, urgent issues which cannot wait should be brought up either on IRC or https://www.mediawiki.org/wiki/Project:Support_desk Thank you for your understanding and sorry for the inconvenience. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Commons-l] Elog.io now up w/ Commons data
Hi Cornelius! For images which it match against the catalog, it should give accurate information. If it doesn't, use the report link to let us know! You're right though that for images it doesn't find in its catalog, we don't provide any information. That's the equivalent of saying this picture may or may not be openly licensed, but right now we have no information to tell either way Sincerely, Jonas On 11 Dec 2014 15:57, Cornelius Kibelka cornelius.kibe...@wikimedia.de wrote: Wow, what a nice and interesting browser extension. Congrats! Just a question: as far as I can see the tool doens't give the complete and correction licensing information, as the source is missing. Or I'm missleading? Best Cornelius 2014-12-10 19:30 GMT+01:00 Jonas Öberg jo...@commonsmachinery.se: Dear all, thanks for all your help with answering questions and giving feedback over the last couple of months. I'm happy to say that we're finally at a stage where we've hashed 22,452,638 images from Wikimedia Commons and launched Elog.io in public beta: http://elog.io/ Elog.io is an open API as well as browser plugins, that can query and get information about images using a perceptual hash that's easy and quick to calculate in a browser. What the browser extensions allow you to do is match an image you find in the wild against Wikimedia Commons. If it can be matched against an image from Commons, it'll show you the title, author, and license, and give you links back to Wikimedia, the license, and a quick and handy Copy as HTML to copy the image and attribution as a HTML snippet for pasting into Word, LibreOffice, Wordpress, etc. Our API provides lookup functions to find information using a URL (the Commons' page name URL) or using the perceptual hash. You get information back as JSON in W3C Media Annotations format. of course, the information you get back is no better than the one provided by the Commons API, so if you already have a page name URL, you may as well query it directly, and rely on our API only for searching by perceptual hashes. The algorithm we use for calculating perceptual hashes, which you'll need to query our API, is at http://blockhash.io/ Sincerely, Jonas ___ Commons-l mailing list common...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l -- Cornelius Kibelka International Affairs Werkstudent | student trainee Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin Tel.: +49 30 219158260 http://wikimedia.de http://wikimedia.de/Stellen Sie sich eine Welt vor, in der jeder Mensch freien Zugang zu der Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei! http://spenden.wikimedia.de/ Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Commons-l mailing list common...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] What to do with TimedMediaHandler
So for a while now, I have been toying a bit with TimedMediaHandler/MwEmbed/TimedText, with the long term goal of wanting it to be compatible with VE, live preview, flow etc. There is a significant challenge here, that we are sort of conveniently ignoring because stuff 'mostly works' currently and the MM team having their plate full with plenty of other stuff: 1: There are many patches in our modules that have not been merged upstream 2: There are many patches upstream that were not merged in our tree 3: Upstream re-uses RL and much infrastructure of MW, but is also significantly behind. They still use php i18n, and their RL classes themselves are also out of date (1.19 style ?). This makes it difficult to get 'our' changes merged upstream, because we need to bring any RL changes etc with it as well. 4: No linting and code style checks are in place, making it difficult to assess and maintain quality. 5: Old jQuery version used upstream 6: Lot's of what we consider deprecated methodologies are still used upstream. 7: Upstream has a new skin ?? 8: It uses loader scripts on every page, which really aren't necessary anymore now that we can add modules to ParserOutput, but since I don't fully understand upstream, i'm not sure what is needed to not break upstream in this regard. 9: The JS modules arbitrarily add stuff to the mw. variables, no namespacing there. 10: The RL modules are badly defined, overlap each other and some script files contain what should be in separate modules 11: We have 5 'mwembed' modules, but upstream has about 20, so they have quite a bit more code to maintain and migrate. 12: Brion is working on his ogvjs player which at some point needs to integrate with this as well (Brion already has some patches for this [1]). 13: Kaltura itself seems very busy and doesn't seem to have too much time to help us out. Since some of the code is however highly specific to their use cases, it becomes difficult to validate changes. Oh and the file trees are disjunct between us and upstream, making git merging a lot more troublesome than it should be (anyone got tips ?). This is maintenance hell, we need to come up with a plan here or we are going the way of getting so far out of sync that the cheapest solution will be to start from scratch... So my questions: 1: Is there anything in upstream that we actually want ? I've been hearing about the 'update' that was still coming from there for over a year now, but due to how far both trees are now out of sync, i'm not really holding my breath for that anymore. The last 'proper sync' seems to have been 'Kaltura 1.7' in july 2012.[2] They are now at v2.21.9 2: Who can think of a strategy to fix this ? 3: Or should we just split off our modules and let upstream sort this out ? 4: Should we consider starting something from scratch ? DJ I have done a bit of cleanup [3] with jshint and jscs on the modules that we use. There are some remaining problems [4], some of which are true bugs in the code. I don't intend to propose these changes for merging any time soon, since it will probably make consolidation of the two variants even more complicated, but I'll try to keep it up to date and maybe try to fix some of these bugs upstream or in MW. [1] https://gerrit.wikimedia.org/r/#/c/165477/ https://gerrit.wikimedia.org/r/#/c/165478/ https://gerrit.wikimedia.org/r/#/c/165479/ [2] https://gerrit.wikimedia.org/r/#/c/16468/ [3] https://github.com/hartman/mwEmbed/compare/jscleanup [4] https://phabricator.wikimedia.org/P147 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What to do with TimedMediaHandler
Sorry about the shameless plug, but I'd love to add this to the list: Integration TimedText with Translate. Phab: https://phabricator.wikimedia.org/T44495 Most of your list is technical debt, whereas translation would be an actual feature, and possibly not even a very complicated one to do. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2014-12-11 17:55 GMT+02:00 Derk-Jan Hartman d.j.hartman+wmf...@gmail.com: So for a while now, I have been toying a bit with TimedMediaHandler/MwEmbed/TimedText, with the long term goal of wanting it to be compatible with VE, live preview, flow etc. There is a significant challenge here, that we are sort of conveniently ignoring because stuff 'mostly works' currently and the MM team having their plate full with plenty of other stuff: 1: There are many patches in our modules that have not been merged upstream 2: There are many patches upstream that were not merged in our tree 3: Upstream re-uses RL and much infrastructure of MW, but is also significantly behind. They still use php i18n, and their RL classes themselves are also out of date (1.19 style ?). This makes it difficult to get 'our' changes merged upstream, because we need to bring any RL changes etc with it as well. 4: No linting and code style checks are in place, making it difficult to assess and maintain quality. 5: Old jQuery version used upstream 6: Lot's of what we consider deprecated methodologies are still used upstream. 7: Upstream has a new skin ?? 8: It uses loader scripts on every page, which really aren't necessary anymore now that we can add modules to ParserOutput, but since I don't fully understand upstream, i'm not sure what is needed to not break upstream in this regard. 9: The JS modules arbitrarily add stuff to the mw. variables, no namespacing there. 10: The RL modules are badly defined, overlap each other and some script files contain what should be in separate modules 11: We have 5 'mwembed' modules, but upstream has about 20, so they have quite a bit more code to maintain and migrate. 12: Brion is working on his ogvjs player which at some point needs to integrate with this as well (Brion already has some patches for this [1]). 13: Kaltura itself seems very busy and doesn't seem to have too much time to help us out. Since some of the code is however highly specific to their use cases, it becomes difficult to validate changes. Oh and the file trees are disjunct between us and upstream, making git merging a lot more troublesome than it should be (anyone got tips ?). This is maintenance hell, we need to come up with a plan here or we are going the way of getting so far out of sync that the cheapest solution will be to start from scratch... So my questions: 1: Is there anything in upstream that we actually want ? I've been hearing about the 'update' that was still coming from there for over a year now, but due to how far both trees are now out of sync, i'm not really holding my breath for that anymore. The last 'proper sync' seems to have been 'Kaltura 1.7' in july 2012.[2] They are now at v2.21.9 2: Who can think of a strategy to fix this ? 3: Or should we just split off our modules and let upstream sort this out ? 4: Should we consider starting something from scratch ? DJ I have done a bit of cleanup [3] with jshint and jscs on the modules that we use. There are some remaining problems [4], some of which are true bugs in the code. I don't intend to propose these changes for merging any time soon, since it will probably make consolidation of the two variants even more complicated, but I'll try to keep it up to date and maybe try to fix some of these bugs upstream or in MW. [1] https://gerrit.wikimedia.org/r/#/c/165477/ https://gerrit.wikimedia.org/r/#/c/165478/ https://gerrit.wikimedia.org/r/#/c/165479/ [2] https://gerrit.wikimedia.org/r/#/c/16468/ [3] https://github.com/hartman/mwEmbed/compare/jscleanup [4] https://phabricator.wikimedia.org/P147 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tech Talk: Phabricator for Wikimedia Projects: Dec 11
This Tech Talk starts in 20 min! On Tue, Dec 2, 2014 at 3:48 PM, Rachel Farrand rfarr...@wikimedia.org wrote: Please join us for the following tech talk: *Tech Talk**:* Phabricator for Wikimedia projects *Presenter:* Quim Gil Andre Klapper *Date:* Dec 11 *Time:* 1800 UTC http://www.timeanddate.com/worldclock/fixedtime.html?msg=Phab+Tech+Talkiso=20141211T00p1=1440ah=1 Link to live YouTube stream http://www.youtube.com/watch?v=_yr5z9Ix2f8 *IRC channel for questions/discussion:* #wikimedia-office Google+ page https://plus.google.com/u/0/b/103470172168784626509/events/cjb4le2ntnqogbbubmjrm9ikq1s, another place for questions *Talk description: * Phabricator is a collaboration platform open to all Wikimedians. We focus on bug reporting and software projects. Non-technical initiatives are welcome as well. Did you know that the first reason why we chose Phabricator was to serve as project management tool? Wikimedians use/used a variety of tools for project management: Trello, Mingle, Scrumbugz, Bugzilla, Asana, Google Docs, and of course wiki pages too. In this demo-based session we will explain how to organize your work with Phabricator at a project level, team level, and individual level. How to set projects, priorities, and tags, how to manage workboards and dashboards, how to organize sprints. Thanks! Rachel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Our CAPTCHA is very unfriendly
Max Semenik wrote: I'm pretty sure most users technical enough to use IRC are able to solve captchas well. That the backend is irc-based doesn't mean the would use a IRC frontend. We routinely point to web irc, and plenty of noobs have proven able to reach there (sometimes even thinking we are $Company since, after all, who else could you be talking to after following a Contact link on a [[$Company]] page at wikipedia.org?) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Multimedia] What to do with TimedMediaHandler
This is a fair assessment of the challenges / divergent code bases. In terms of a path forward, I think it’s worth highlighting how the Kaltura player normally integrates with other stand alone entity providers now days. We normally integrate via a media proxy library that basically normalizes representation of stream sources, media identifiers, structured and unstructured metadata, captions, cuePoints, content security protocols to a “Kaltura like” representation then the CMS’s consume the kaltura player iframe services in a way that is almost identical to our Kaltura Platform style embeds, just overriding identifiers. This makes the iframe player service easy to be consumed by our native components, twitter embeds etc. See architecture overview here. [1] You can see what this looks like with a mediaProxy override sample [2] Is this useful for wikimedia use case? … not so sure ... since the review scope would grow a lot if we had the player serving its own iframe independently of the rest of code infrastructure it would otherwise duplicate many components, and reduce insensitive to align versions of things. Some significant brainstorming and alignment would need to take place which has awaited a focus from the multimedia team; since we would want to focus efforts towards something that would be sustainable for both organizations going forward both from community and organization contributions so the projects could better benefit each other. * Kaltura will move quickly to review and integrate the code styling / js-hint updates something we have intended to do for a while. Other low hanging fruit alignments have already been integrated, by some early work on this by paladox2015 ( github id ). * Kaltura would be interested in working to make things as easy as possible to use the library in both context; but we need “a plan”. While things have drifted significantly there is paths towards upgrading things, a goal to align code conventions [3] means the projects share a lot more then say some arbitrary other project out there that would do everything its own way ;) * That being said, the possibility for WMF to use something new should evaluated, but again should involve multimedia team within WMF so that the cost benefit analysis can be mapped out per organization infrastructure support; or a similar situation will crop up after a sprint of effort produced something usable, but was not maintained going forward. [1] http://knowledge.kaltura.com/sites/default/files/styles/large/public/kaltura-player-toolkit.png http://knowledge.kaltura.com/sites/default/files/styles/large/public/kaltura-player-toolkit.png [2] http://kgit.html5video.org/pulls/1194/modules/KalturaSupport/tests/StandAlonePlayerMediaProxyOverride.html http://kgit.html5video.org/pulls/1194/modules/KalturaSupport/tests/StandAlonePlayerMediaProxyOverride.html 3] https://github.com/kaltura/mwEmbed/#hacking-on-mwembed https://github.com/kaltura/mwEmbed/#hacking-on-mwembed On Dec 11, 2014, at 7:55 AM, Derk-Jan Hartman d.j.hartman+wmf...@gmail.com wrote: So for a while now, I have been toying a bit with TimedMediaHandler/MwEmbed/TimedText, with the long term goal of wanting it to be compatible with VE, live preview, flow etc. There is a significant challenge here, that we are sort of conveniently ignoring because stuff 'mostly works' currently and the MM team having their plate full with plenty of other stuff: 1: There are many patches in our modules that have not been merged upstream 2: There are many patches upstream that were not merged in our tree 3: Upstream re-uses RL and much infrastructure of MW, but is also significantly behind. They still use php i18n, and their RL classes themselves are also out of date (1.19 style ?). This makes it difficult to get 'our' changes merged upstream, because we need to bring any RL changes etc with it as well. 4: No linting and code style checks are in place, making it difficult to assess and maintain quality. 5: Old jQuery version used upstream 6: Lot's of what we consider deprecated methodologies are still used upstream. 7: Upstream has a new skin ?? 8: It uses loader scripts on every page, which really aren't necessary anymore now that we can add modules to ParserOutput, but since I don't fully understand upstream, i'm not sure what is needed to not break upstream in this regard. 9: The JS modules arbitrarily add stuff to the mw. variables, no namespacing there. 10: The RL modules are badly defined, overlap each other and some script files contain what should be in separate modules 11: We have 5 'mwembed' modules, but upstream has about 20, so they have quite a bit more code to maintain and migrate. 12: Brion is working on his ogvjs player which at some point needs to integrate with this as well (Brion already has some patches for this [1]). 13: Kaltura itself seems very busy and doesn't seem to have too
Re: [Wikitech-l] A new extension of content tree about Wikipedia
I think we should explore this. I don't think this is about extra clicks... On tablets like desktop we expand sections by default but __allow___ them to be collapsible. It would be interesting to add some event logging to see how widely used that feature is on tablet. It could thus also be useful for desktop and I wouldn't outright dismiss it without evidence to backup it's usefulness. Like Eallan I find this feature useful on both mobile and desktop (I use mobile site as my desktop experience) for navigating around complex documents. Eallan happy to combine brainpower and work out a sensible test to see if it is useful or not if you are. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Andrew Garret joins the Wikimedia Foundation
Il 03/11/2014 22:22, Tomasz Finc ha scritto: I am pleased to announce Andrew Garret joining the Wikimedia Foundation as a full time Software Engineer I think you missed a 't': mw:User:Andrew Garrett (WMF) https://www.mediawiki.org/wiki/User:Andrew_Garrett_%28WMF%29 Andrew has been contracting with the Wikimedia Foundation for over six years now and its only fitting to announce that now that he's done with his studies he'll be going full time at the Wikimedia Foundation. In the past six years, he's worked on a huge variety of projects, ranging from user preferences and spam filtering to notifications and two attempts to fix talk pages. He's passionate about making people’s workflows and processes make sense, so in the coming months, he's looking forward to having the time and energy to focus on software that humanizes our projects, eliminates busy work, and makes life easier for new and old contributors. Right now Andrew is in the process of moving from Sydney to Maastricht to be with his girlfriend He'll be working from Maastricht; and from early next year, Prague. So if you find yourself in one of those cities, you should let him know! When not working, doing assignments, or packing bags, Andrew is busy travelling or homebrewing. He's currently supporting the Flow team and we're exploring where he'll help next. Please join me in celebrating Andrew going full time --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
