[Wikitech-l] Javascript to find other articles having the same external link
By putting the following code (written by User:EnDumEn) in
user:YOURNAME/common.jsany external link gets an extra little
symbol (⎆), which leads to a link search for that link. This
is very useful for finding other articles that cite the same
source.
jQuery( a.external ).after( function() {
return jQuery( a⎆/a) )
.attr( href, //sv.wikipedia.org/wiki/Special:Linksearch/ + this.href )
.before( );
});
--
Lars Aronsson (l...@aronsson.se)
Aronsson Datateknik - http://aronsson.se
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Javascript to find other articles having the same external link
Hoi,
With sources stored in Wikidata finding where the same source is used as
well is implicit. This is a hack, admittedly a nice hack/.
Thanks,
GerardM
On 26 August 2013 09:27, Lars Aronsson l...@aronsson.se wrote:
By putting the following code (written by User:EnDumEn) in
user:YOURNAME/common.jsany external link gets an extra little
symbol (⎆), which leads to a link search for that link. This
is very useful for finding other articles that cite the same
source.
jQuery( a.external ).after( function() {
return jQuery( a⎆/a) )
.attr( href,
//sv.wikipedia.org/wiki/**Special:Linksearch/http://sv.wikipedia.org/wiki/Special:Linksearch/
+ this.href )
.before( );
});
--
Lars Aronsson (l...@aronsson.se)
Aronsson Datateknik - http://aronsson.se
__**_
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Javascript to find other articles having the same external link
I'd love to see a similar thing for articles linking to the same book via
ISBN.
regards,
Ole
On Mon, Aug 26, 2013 at 9:46 AM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:
Hoi,
With sources stored in Wikidata finding where the same source is used as
well is implicit. This is a hack, admittedly a nice hack/.
Thanks,
GerardM
On 26 August 2013 09:27, Lars Aronsson l...@aronsson.se wrote:
By putting the following code (written by User:EnDumEn) in
user:YOURNAME/common.jsany external link gets an extra little
symbol (⎆), which leads to a link search for that link. This
is very useful for finding other articles that cite the same
source.
jQuery( a.external ).after( function() {
return jQuery( a⎆/a) )
.attr( href, //sv.wikipedia.org/wiki/**Special:Linksearch/
http://sv.wikipedia.org/wiki/Special:Linksearch/
+ this.href )
.before( );
});
--
Lars Aronsson (l...@aronsson.se)
Aronsson Datateknik - http://aronsson.se
__**_
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
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
--
http://palnatoke.org * @palnatoke * +4522934588
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Javascript to find other articles having the same external link
Hoi,
grin the same book or also the same book in translation? /grin
Can be theoretically be linked in Wikidata too.
Thanks,
GerardM
On 26 August 2013 10:07, Ole Palnatoke Andersen o...@palnatoke.org wrote:
I'd love to see a similar thing for articles linking to the same book via
ISBN.
regards,
Ole
On Mon, Aug 26, 2013 at 9:46 AM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:
Hoi,
With sources stored in Wikidata finding where the same source is used as
well is implicit. This is a hack, admittedly a nice hack/.
Thanks,
GerardM
On 26 August 2013 09:27, Lars Aronsson l...@aronsson.se wrote:
By putting the following code (written by User:EnDumEn) in
user:YOURNAME/common.jsany external link gets an extra little
symbol (⎆), which leads to a link search for that link. This
is very useful for finding other articles that cite the same
source.
jQuery( a.external ).after( function() {
return jQuery( a⎆/a) )
.attr( href, //sv.wikipedia.org/wiki/**Special:Linksearch/
http://sv.wikipedia.org/wiki/Special:Linksearch/
+ this.href )
.before( );
});
--
Lars Aronsson (l...@aronsson.se)
Aronsson Datateknik - http://aronsson.se
__**_
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
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
--
http://palnatoke.org * @palnatoke * +4522934588
___
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] WMFs stance on non-GPL code
On 26-08-2013 02:59, Tyler Romeo wrote: On Sun, Aug 25, 2013 at 8:30 PM, Brian Wolff bawo...@gmail.com wrote: I'd be surprised if there was a problem with any open source license. Well if it's a MediaWiki extension, it has to be GPL-compatible, otherwise using it as part of MediaWiki violates the core's own GPL license. Wrong. WMF can use any software they like on their servers... even propriatary software. They are _using_ it, not _distributing_ it. Compatible licencing is only relevant on software that is distributed, in the WMF's case, MediaWiki and related extensions. -- Erwin Dokter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Javascript to find other articles having the same external link
On Mon, Aug 26, 2013 at 10:07:16AM +0200, Ole Palnatoke Andersen wrote:
I'd love to see a similar thing for articles linking to the same book via
ISBN.
You can do that in the JavaScript just by adding to the selector at the
beginning, and you can also get other magic links at the same time.
jQuery( a.external, a.mw-magiclink-isbn, a.mw-magiclink-pmid,
a.mw-magiclink-rfc ).after( function() {
return jQuery( a )
.text( '⎆' )
// Shorter, relative link (could also use mw.Title here maybe)
.attr( href, /wiki/Special:Linksearch/ + this.href )
.before( );
} );
But it looks like Special:Linksearch doesn't support searching for magic
links, at least not yet. So I'm afraid this is all for nought.
I'm going to hope that CirrusSearch will fix this in some capacity, since
it looks pretty simple to fix, and if Chad would like some help with that,
he knows where to find me...
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtrac...@member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Javascript to find other articles having the same external link
On 2013-08-26 8:55 AM, Mark Holmquist mtrac...@member.fsf.org wrote:
On Mon, Aug 26, 2013 at 10:07:16AM +0200, Ole Palnatoke Andersen wrote:
I'd love to see a similar thing for articles linking to the same book
via
ISBN.
You can do that in the JavaScript just by adding to the selector at the
beginning, and you can also get other magic links at the same time.
jQuery( a.external, a.mw-magiclink-isbn, a.mw-magiclink-pmid,
a.mw-magiclink-rfc ).after( function() {
return jQuery( a )
.text( '⎆' )
// Shorter, relative link (could also use mw.Title here maybe)
.attr( href, /wiki/Special:Linksearch/ + this.href )
.before( );
} );
But it looks like Special:Linksearch doesn't support searching for magic
links, at least not yet. So I'm afraid this is all for nought.
I'm going to hope that CirrusSearch will fix this in some capacity, since
it looks pretty simple to fix, and if Chad would like some help with that,
he knows where to find me...
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtrac...@member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
For reference that's https://bugzilla.wikimedia.org/show_bug.cgi?id=49537
Arguably they aren't really external links and shouldn't be tracked with
them, otoh a table just for magic links seem overkill.
-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikimedia Commons mobile photo uploader app updated on iOS and Android
Rupert, I saw your question regarding Wikipedia Zero. Wikipedia Zero is currently targeted for the mobile web, but I'll take this question back to the business team as to whether we'd be able to support zero-rating of apps traffic at some point in the future, at least in locales where moderate bandwidth is available. Thanks! -Adam On Sun, Aug 25, 2013 at 1:55 PM, Yuvi Panda yuvipa...@gmail.com wrote: On Mon, Aug 26, 2013 at 2:01 AM, rupert THURNER rupert.thur...@gmail.com wrote: created https://bugzilla.wikimedia.org/show_bug.cgi?id=53328, maybe you could detail a little bit more how this api should look like? See https://bugzilla.wikimedia.org/show_bug.cgi?id=46072 (thanks Liangent!) -- Yuvi Panda T http://yuvi.in/blog ___ 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] MediaWiki's Login Security
On Sat, Aug 24, 2013 at 10:05 AM, Tyler Romeo tylerro...@gmail.com wrote: On Sat, Aug 24, 2013 at 12:50 PM, Seb35 seb35wikipe...@gmail.com wrote: An other solution is the use of one-time passwords [1] for high-security or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser action). Such one-time passwords can be generated entirely on the client side (e.g. a program) or on an external device (e.g. SecurID [2]). This transfers the problem unsecure password to a problem protection of the password generator (e.g. with an offline password) and introduces the key distribution problem (e.g. the physical device). Would something like Extension:OATHAuth fit this purpose? The OATH protocol, definitely. One piece I wasn't able to get into our Auth rework this summer was having 2-step login, so that we could require OATH for some people, but normal users wouldn't have to. But yeah, *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ 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] MediaWiki's Login Security
On Mon, Aug 26, 2013 at 11:50 AM, Chris Steipp cste...@wikimedia.orgwrote: One piece I wasn't able to get into our Auth rework this summer was having 2-step login, so that we could require OATH for some people, but normal users wouldn't have to. But yeah, Yeah...that's a little bit of my fault. Once the merger between Extension:OATHAuth and Extension:TwoFactorAuthentication is complete, that feature will exist. See bug 53195. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feedback/testing wanted: SecureLogin on test2.wikipedia.org
On Sat, Aug 24, 2013 at 6:38 PM, Greg Grossmeier g...@wikimedia.org wrote: Hello all, We have enabled the newly updated SecureLogin on http://test2.wikipedia.org Big thanks to Chris and Chad getting this work finalized on Friday and taking a bit of their weekend today/tomorrow. This is the work described here: https://www.mediawiki.org/wiki/Requests_for_comment/Login_security The plan of record for what the various questions is summarized here: http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071441.html (also in above RFC) Go forth and test! Provide feedback! Reply here and/or report bugs, please. Testing is now extended to mediawiki.org as well. I also merged the GeoIP config changes. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMFs stance on non-GPL code
Stated more precisely: a non-GPL-compatible license for an extension means that the extension can never be distributed with core. The idea that deployment of software on a server entails license obligations is a GPLv3 feature; mediawiki is licensed under the GPL v2 (or later for theoretical redistribution purposes). Presumably deployment of a GPLv3-only or [[Affero GPL]] extension on a WMF server might be more problematic, iff WMF were deploying non-GPL-compatible extensions (I don't know whether that's the case one way or another). But that's rather orthogonal to the openness of the source. Anyway, we could devolve into a flame war and/or discussion of the merits and disadvantages of various software licenses rather easily, so I'm suggesting that we limit further discussion on this thread absent a more focused question from Jeroen. --scott -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Weighted random article
On Sat, Aug 24, 2013 at 6:38 PM, Maarten Dammers maar...@mdammers.nlwrote: If you compare our current implementation to wheel of fortune [1]; all our articles are evenly spread around. Weighted would be putting bot articles closer to each other so you would hit them less often. You just need a good algorithm to calculate this distribution. You could implement this algorithm as an extension in MediaWiki that updates page_random with this different distribution. This way you don't need to update the database schema, just the logic at the page save. As a simple implementation: normally articles are saved with a random sort key between 0 and 1. If bot articles were saved with a random sort key between 0 and 0.1, they would expect to be seen by Special:RandomPage 10 times less often than they were previously. (Ie, if there were a b% chance of getting a bot page from Special:RandomPage previously, there would now be a (b/10)% chance of getting a bot page.) --scott ps. If you want to be numerically precise, you need to be more careful with the edge conditions. For example, if there are no non-bot articles, then 90% of the time the algorithm will end up wrapping around and choosing the lowest-sorted bot article, which would warp the expected distribution. It would be more correct to re-roll the dice in that case, which introduces an extra term into the probability which ends up resolving the apparent contradiction when b=100%.. -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Etherpad Lite labs instance going down in two weeks - backup time
On Sat, Aug 24, 2013 at 1:49 AM, Federico Leva (Nemo) nemow...@gmail.comwrote: I already have been archiving my stuff from etherpad on wiki, of course, and I've never ever used etherpad.wmflabs.org because I knew everything in Labs can die any time, but this doesn't mean that I don't worry for what others will lose. Of course I understand it's not the _responsibility_ of Labs folks nor ops, but still it would be nice if someone managed to do something about it. If I was provided with a list of all existing pads I could do something myself; I only found few links from our wikis https://toolserver.org/~**nemobis/tmp/ethlabs.txthttps://toolserver.org/~nemobis/tmp/ethlabs.txt Some people may have placed sensitive info in the pads, assuming some level of (misguided) privacy since the pages weren't indexed. We're not planning on doing dumps or even exposing an index. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Etherpad Lite labs instance going down in two weeks - backup time
On Aug 26, 2013, at 2:18 PM, Ryan Lane rlan...@gmail.com wrote: Some people may have placed sensitive info in the pads, assuming some level of (misguided) privacy since the pages weren't indexed. We're not planning on doing dumps or even exposing an index. To further clarify, we'll be keeping a dump in case there's some incredibly critical information that was inadvertently pasted into a pad despite the many and various warnings about the ephemeral nature of the service - but as Ryan said, we have no intention of indexing or even investigating this dump unless necessary, and would definitely not release it as a whole for the reasons mentioned. Thanks. --Ken. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMFs stance on non-GPL code
Well if it's a MediaWiki extension, it has to be GPL-compatible, otherwise using it as part of MediaWiki violates the core's own GPL license. Wrong. WMF can use any software they like on their servers... even propriatary software. They are _using_ it, not _distributing_ it. Compatible licencing is only relevant on software that is distributed, in the WMF's case, MediaWiki and related extensions. I wasn't even aware though that extensions to be distributed needed to be licensed under something that is GPL compatible. It's been a while since I read the GPL. Looking back over it again (well the FAQ actually), that is very non-intuitive... we'd need to fork the Mediawiki process to allow non-GPL extensions to be distributed? I might have to look into licenses again and make sure what I use is GPL compatible. The GPL is such a pain sometimes Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMFs stance on non-GPL code
On Mon, Aug 26, 2013 at 3:35 PM, Derric Atzrott datzr...@alizeepathology.com wrote: I might have to look into licenses again and make sure what I use is GPL compatible. The GPL is such a pain sometimes https://fedoraproject.org/wiki/Licensing:Main is a useful guide. --scott -- (http://cscott.net) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMFs stance on non-GPL code
VisualEditor is MIT licensed. It was originally GPLv2 by default as per my contract with Wikimedia, but early on we got written permission from all authors to change it. We did this because we wanted to ensure maximum license compatibility for re-use in non-MediaWiki systems. - Trevor On Mon, Aug 26, 2013 at 12:43 PM, C. Scott Ananian canan...@wikimedia.orgwrote: On Mon, Aug 26, 2013 at 3:35 PM, Derric Atzrott datzr...@alizeepathology.com wrote: I might have to look into licenses again and make sure what I use is GPL compatible. The GPL is such a pain sometimes https://fedoraproject.org/wiki/Licensing:Main is a useful guide. --scott -- (http://cscott.net) ___ 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] WMFs stance on non-GPL code
On Mon, Aug 26, 2013 at 12:55 PM, Trevor Parscal tpars...@wikimedia.orgwrote: VisualEditor is MIT licensed. It was originally GPLv2 by default as per my contract with Wikimedia, but early on we got written permission from all authors to change it. We did this because we wanted to ensure maximum license compatibility for re-use in non-MediaWiki systems. Aren't our contracts generally written to allow us to use any OSI compliant license, with a preference to GPL 2? - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMFs stance on non-GPL code
As long as it is a separate extension there is no problem, but if you bundle it in such a way that it is an integral part of the core then you might get into trouble. On Mon, Aug 26, 2013 at 9:35 PM, Derric Atzrott datzr...@alizeepathology.com wrote: Well if it's a MediaWiki extension, it has to be GPL-compatible, otherwise using it as part of MediaWiki violates the core's own GPL license. Wrong. WMF can use any software they like on their servers... even propriatary software. They are _using_ it, not _distributing_ it. Compatible licencing is only relevant on software that is distributed, in the WMF's case, MediaWiki and related extensions. I wasn't even aware though that extensions to be distributed needed to be licensed under something that is GPL compatible. It's been a while since I read the GPL. Looking back over it again (well the FAQ actually), that is very non-intuitive... we'd need to fork the Mediawiki process to allow non-GPL extensions to be distributed? I might have to look into licenses again and make sure what I use is GPL compatible. The GPL is such a pain sometimes Thank you, Derric Atzrott ___ 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] WMFs stance on non-GPL code
Le 26/08/13 22:03, Ryan Lane a écrit : Aren't our contracts generally written to allow us to use any OSI compliant license, with a preference to GPL 2? My company has a joint copyright agreement with Wikimedia. So I guess the foundation can publish the work under whatever license :) My code is licensed under GPLv2+ and the rest under CC-BY-SA (unless mentioned otherwise). -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMFs stance on non-GPL code
On Mon, Aug 26, 2013 at 10:12 AM, C. Scott Ananian canan...@wikimedia.orgwrote: The idea that deployment of software on a server entails license obligations is a GPLv3 feature; To be clear, that's AGPL-only, not GPL v3. Luis -- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810 NOTICE: *This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.* ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikimediaMobile] Wikimedia Commons mobile photo uploader app updated on iOS and Android
On Mon, Aug 26, 2013 at 8:19 AM, Adam Baso ab...@wikimedia.org wrote: Rupert, I saw your question regarding Wikipedia Zero. Wikipedia Zero is currently targeted for the mobile web, but I'll take this question back to the business team as to whether we'd be able to support zero-rating of apps traffic at some point in the future, at least in locales where moderate bandwidth is available. I think that once the zero-rating is switched to support HTTPS by using IP-based instead of Deep Packet Inspection-based HTTP sniffing, ISP partners wouldn't actually be able to distinguish between mobile web and mobile apps content unless we actively choose to make them use separate IPs and domain names. Especially if, as we think we're going to, the future Wikipedia mobile app will consist mostly of native code widgets and modules that plug into the web site embedded in a web control... it'll be loading mostly the same web pages from the same servers, but running a different mix of JavaScript. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Commons mobile photo uploader app updated on iOS and Android
On Tue, Aug 20, 2013 at 2:44 PM, Strainu strain...@gmail.com wrote: 2013/8/21 Brion Vibber bvib...@wikimedia.org: (The Commons uploader apps may or may not eventually roll into the main Wikipedia app on iOS and Android too, we haven't decided for sure yet.) That sound weird (read: divergent from all the stuff we read in the WMF plans and reports). Shouldn't the ultimate development goal for mobile be total feature parity with desktop? Pretty much yes parity is what we want! But it'll take some time to redo the overall UI of Commons on the desktop to not be awful ;) and there's always a different set of capabilities available to us on different platforms. Note that UploadWizard provides much similar functionality in uploading on the desktop (but with poor offline batching and no direct camera support, and for large batch uploads there are some usability issues). A similar view of your uploads to what the Commons app gives can be gotten on the desktop by jumping through a couple hoops -- https://commons.wikimedia.org/wiki/Special:MyFiles -- and a more direct analog is integrated and linked from the sidebar on mobile web -- try https://commons.m.wikimedia.org/wiki/Special:Uploads ... In the future, there'll be more and more convergence as the browsers improve support for native device functions and offline storage. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Javascript to find other articles having the same external link
On 2013-08-26 8:06 AM, Brian Wolff wrote: On 2013-08-26 8:55 AM, Mark Holmquist mtrac...@member.fsf.org wrote: On Mon, Aug 26, 2013 at 10:07:16AM +0200, Ole Palnatoke Andersen wrote: ... But it looks like Special:Linksearch doesn't support searching for magic links, at least not yet. So I'm afraid this is all for nought. I'm going to hope that CirrusSearch will fix this in some capacity, since it looks pretty simple to fix, and if Chad would like some help with that, he knows where to find me... -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtrac...@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist For reference that's https://bugzilla.wikimedia.org/show_bug.cgi?id=49537 Arguably they aren't really external links and shouldn't be tracked with them, otoh a table just for magic links seem overkill. -bawolff Maybe we can fit them into page_props somehow. Did we have support for 1:many instead of just 1:1 keys in page_props? ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla: Separate bug report status when patch is in Gerrit?
On 06/06/2013 11:16 AM, Alex Monk wrote: Also, +1 to a Fixes-Bug: 123 annotation or somesuch, as Timo proposed a couple of months ago in the rather more cryptic Bug 123 vs. Bug: 123. +1 from me as well. Filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=53387 Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
