Re: [Wikitech-l] Fwd: [wikimedia #5841] etherpad.wikimedia.org downtime due to upgrade
Hello Federico, Some (but not all) of the etherpad links you provided do not have any content. There are two ways to proceed. If they are new enough (after 2013-08-19) it might be a bug in etherpad-lite. In that case we should wait for the upgrade, try to reproduce and fill a bug report to the authors of the software. I am afraid the content of the pad is probably lost. If they are old enough (before 2013-08-19), there probably was a problem with the migration from the old etherpad to the new one. The scripts provided by the authors to do the migration were buggy enough to justify such a problem. We did have to copy some pads manually, however the ones you list were not among them. In that case it is still possible to recover the content of the pad from the old etherpad installation (we have kept it around). All you need to do is access it via http://etherpad-old.wikimedia.org instead of http://etherpad.wikimedia.org On Fri, Sep 27, 2013 at 10:53 PM, Federico Leva (Nemo) wrote: > What should I do if a number of etherpads seem to be completely gone? > Can someone click on any of the pad links on > https://meta.wikimedia.org/wiki/Wikimedia_Conference_2013/Schedule/Saturday > and tell me if they are able to see some content? Thanks. > > Nemo > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Alexandros Kosiaris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [wikimedia #5841] etherpad.wikimedia.org downtime due to upgrade
FYI, -- Forwarded message -- From: Date: Mon, Sep 30, 2013 at 2:12 PM Subject: Fwd: [wikimedia #5841] etherpad.wikimedia.org downtime due to upgrade etherpad-lite has been successfully update to version 1.2.11. The upgrade procedure server-wise was uneventfull, however it will cause some minor problems to existing users of the service. Specifically CSS/JS elements of the page have changed and need to be re-downloaded by the browser, however due to browser caching this does not happen automatically. Users of the old version will have to FORCE REFRESH their browser when accessing the service for the first time. Otherwise they will get garbled versions of the user interface. Pad contents will be intact, however a brief message suggesting the user does not have permission to access a pad might show up. That message is inaccurate and is a by-product of the garbled UI. -- Alexandros Kosiaris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Inline bug report history in Bugzilla
Hola, if you have found yourself clicking the "History" link in Bugzilla tickets way too often (to check who has set the Priority, or who has changed the assignee and when), Bugzilla now has an opt-in to display such metadata changes inline, between the comments of the bug report. You can enable this by going to https://bugzilla.wikimedia.org/userprefs.cgi?tab=settings and setting "When viewing a bug, show all bug activity" to "On". Cheers, 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] Inline bug report history in Bugzilla
wh nice feature On Mon, Sep 30, 2013 at 5:01 PM, Andre Klapper wrote: > Hola, > > if you have found yourself clicking the "History" link in Bugzilla > tickets way too often (to check who has set the Priority, or who has > changed the assignee and when), Bugzilla now has an opt-in to display > such metadata changes inline, between the comments of the bug report. > > You can enable this by going to > https://bugzilla.wikimedia.org/userprefs.cgi?tab=settings > and setting "When viewing a bug, show all bug activity" to "On". > > Cheers, > 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline bug report history in Bugzilla
Andre, This is brilliant, and makes Bugzilla hugely more usable; could it be switched on for all users by default, or would that impair the server operation too much? J. On 30 September 2013 08:01, Andre Klapper wrote: > Hola, > > if you have found yourself clicking the "History" link in Bugzilla > tickets way too often (to check who has set the Priority, or who has > changed the assignee and when), Bugzilla now has an opt-in to display > such metadata changes inline, between the comments of the bug report. > > You can enable this by going to > https://bugzilla.wikimedia.org/userprefs.cgi?tab=settings > and setting "When viewing a bug, show all bug activity" to "On". > > Cheers, > 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 -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikimediaMobile] webfonts in mobile frontend
Thanks Amir for kicking this off! A general point I wanted to make off the back of this... when adding things to the mobile site, no matter how minimal a module is we should get in the discipline habit of thinking "Does everyone need this module?" We should be extremely careful what JavaScript and CSS modules we add to mobile users, especially when modules are not useful to certain users. In this case I would recommend checking if the language needs WebFonts before adding the module to the page. Another key thing we are doing on mobile now is making use of mw.loader.using to conditionally load JavaScript - this is another useful trick :-). On Fri, Sep 27, 2013 at 10:49 PM, Yuvi Panda wrote: > Forwarded to wikitech-l > > > -- Forwarded message -- > From: Amir E. Aharoni > Date: Sat, Sep 28, 2013 at 10:38 AM > Subject: [WikimediaMobile] webfonts in mobile frontend > To: "mobil...@lists.wikimedia.org" > > > Hi, > > So today I worked with Kaldari (thanks for the help!!) and committed a > very simple module to enable webfonts support in MobileFrontend: > https://gerrit.wikimedia.org/r/#/c/86340/ > https://gerrit.wikimedia.org/r/#/c/86337/ > > Review and any comments are very welcome, of course. > > The current implementation is very simple. It doesn't allow any > configuration or choice of fonts - if there is a default font for the > language, it is used wherever there's a lang attribute or a style or a > class the sets a font explicitly. (Some languages, like Tamil and > Hebrew have fonts, but they are not default, so none are used). It may > be worth optimizing it, for example: > > * Only loading the font of the content language to save time and > bandwidth. (Loading additional fonts can be an option.) > * Only loading fonts on devices that are known to have bad font > support. On iPhone and it's pretty for many languages. On the latest > Windows Mobile version it's very good. On Android below 4.0, however, > it's very bad: most languages of India are completely unreadable, > which is the main reason to do this (the same goes for languages of > Ethiopia, South-East Asia and some others). Android 4 and above is not > always perfect either. > > I'd love to hear more considerations about bandwidth, performance, testing > etc. > > Thanks! > > -- > Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי > http://aharoni.wordpress.com > “We're living in pieces, > I want to live in peace.” – T. Moore > > ___ > Mobile-l mailing list > mobil...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > > -- > Yuvi Panda T > http://yuvi.in/blog > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Improving anti-vandalism tools (twinkle, huggle etc) - suspicious edits queue
I wonder if the refactor described in https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core could be adapted to help with this use case. I suspect it would be highly useful to be able to create publicly viewable watchlists of suspicious edits. With a little bit of tweaking maybe when viewing the watchlist only the suspicious edits would show in the list and users could collectively 'unwatch' them when reviewed? On Fri, Sep 27, 2013 at 7:42 AM, Petr Bena wrote: > Hi, > > I think you perfectly summarized this issue. I like the first solution > (3rd provider on wikimedia labs with some well documented api > interface) but I must admit that identity sharing might be little > problem (if some troll figured out this system and we weren't using > any identification at all, they could easily wipe all edits). > > Having this directly in MW as tags that can be applied by users would > be probably best solution, but I am afraid it's going to take ages for > this to happen > > On Fri, Sep 27, 2013 at 4:21 PM, Aaron Halfaker > wrote: >> I've got to say that this problem seems pretty straightforward. >> Essentially, we need something lighter than 'revert' for edits that need a >> second set of eyes. >> >> What we really want is a queue of suspect revisions that allows Wikipedians >> to flag new revisions, query current flagged revisions and remove revisions >> from the list after review. >> >> I see two clear options: >> >> *3rd party tool. *A queue of suspect revisions can be created as a 3rd >> party tool (e.g. webapp + API running on labs). Then gadgets and other 3rd >> party tools make use of the API to add, remove, update & query the set of >> flagged edits. I worry about this option due to the lack of good identity >> sharing between Wikipedia and 3rd party wiki tools, but otherwise, it seems >> trivial to implement. >> >> *Make use of infrastructure in MediaWiki. *We can either build on top of >> the features currently deployed or on top of new features in the pipeline. >> >> - Current MW: Someone brought up the example of adding a template to >> articles who have recent revisions needing review. Such templates could >> appear on the talk page so as to not clutter the article. I've got to >> admit that this sounds messy, but the user warning level system employed by >> Huggle, ClueBot NG, Twinkle, etc. is equally message. >> >> - New Features: If arbitrary tags could manually be added to revisions and >> queried from the MediaWiki (preferably, the API), the functionality of a >> third party tool described above could be captured without need for >> accessing an external tool. This might require a little bit of gadget >> support for common actions taken on the "suspicious edit queue". >> >> >> On Fri, Sep 27, 2013 at 8:59 AM, John Vandenberg wrote: >> >>> On Fri, Sep 27, 2013 at 8:52 PM, Petr Bena wrote: >>> > Not really, I can't see how tags help at all in here. We are talking >>> > about any kind of edit (nothing that can be matched by regex) which >>> > seems suspicious to vandal-fighter (human) but who can't make sure if >>> > it's vandalism or not. Nothing like abuse filter nor patrolled edits >>> > can help here (unless we mark every single edit as patrolled and these >>> > people who see such a suspicious edit would mark it as un-patrolled or >>> > something like that) >>> >>> If I understand correctly, you want user-applied tags on revisions, >>> which is bug 1189. >>> >>> https://bugzilla.wikimedia.org/show_bug.cgi?id=1189 >>> >>> All edits start out unpatrolled. >>> >>> If your interface shows the union of unpatrolled edits and a >>> huggle-user-selected-tag (be it tor, abusefilter, or manually added >>> tag) .. >>> >>> 'Experts' edit the page if required, and then mark the revision as >>> patrolled so it no longer appears in the queue. >>> >>> -- >>> John Vandenberg >>> >>> ___ >>> 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 > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] IRC office hour for Extension:BetaFeatures
Hi all, Due partly to the recent sparseness of traffic in #wikimedia-office, I've scheduled an office hour [0] for the new BetaFeatures extension, which the WMF is hoping to use for launching new features for beta testing. This will primarily be a technical discussion focused on people who may want to use the framework, or people who may want to help work on the extension. Possible topics include: * How do I use it? * What features are under development in this framework right now? * How does it work? * Can I have feature X? If you have any questions, or want to hear me wax on about what I've done with the extension thus far, drop on by and have a chat. I'll be in #wikimedia-office on Thursday at 21:00 UTC (14:00 PDT). [0] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours Happy hacking, -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Conditional resource loading
Tyler Romeo gmail.com> writes: > On Sat, Sep 28, 2013 at 3:23 PM, Amelia Ireland > gmod.org>wrote: > > > I want to rewrite a couple of extensions to prevent them from loading > > resources unless the extension is active on a page. Is there some > > documentation on this somewhere, or an extension that does > > this whose code I can examine? > > > > This is probably what you're looking for: > > https://www.mediawiki.org/wiki/ResourceLoader/Developing_ > with_ResourceLoader#Client-side_.28dynamically.29 > > There's a JavaScript function mw.loader.using() that loads modules before > calling the passed closure. I've already used this method with one of the extensions. Is there anything on the backend / PHP side so that I can advantage of ResourceLoader script compression? It seems like it should be possible, but I don't have a thorough-enough knowledge of the innards of Mediawiki, and I can't find anything in the docs on this topic. Thanks, Amelia. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Conditional resource loading
On Mon, Sep 30, 2013 at 09:27:29PM +, Amelia Ireland wrote: > I've already used this method with one of the extensions. Is there anything > on the backend / PHP side so that I can advantage of ResourceLoader script > compression? It seems like it should be possible, but I don't have a > thorough-enough knowledge of the innards of Mediawiki, and I can't find > anything in the docs on this topic. As long as you know that the extension is enabled before the page loads or the user takes any actions, you can simply find out where the modules are added to the OutputPage (look/grep for "addModules") and wrap it in an appropriate if statement/block. I don't think ResourceLoader itself has any nice methods to do this for you, but I also don't think it's a particularly useful feature, given the ease with which developers can do it themselves... -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FOSDEM update
Le 25/09/2013 19:39, Quim Gil a écrit : > Wikimedia wants to have a stand, and we have received an offer to help > from the nascent Wikimedia Belgium chapter. Probably more help can be > aggregated from CH, DE, FR, NL, UK + other tech contributors in the > region? Let's do something really cool! To be discussed. Kiwix and openZIM people never attend to the FOSDEM in the past. This is something we seriously think to change next year with the help of Wikimedia CH. If there is a Wikimedia booth, we would be really happy to help to animate it. Regards Emmanuel -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
