[Wikitech-l] Current status of IPv6 connectivity?
Hi, Are there any reports that could allow one to check the status of IPv6 connectivity in the WMF cluster? If not, could you let me know if IPv6 is deployed on all servers and if you consider it stable? I'm seeing huge variations in IPv6 performance when connecting to WMF servers, while the rest of the internet seems to work and I'm trying to determine if the problem is on my side, somewhere on the way, or in the WMF network. Thanks, Strainu ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
FWIW I also wrote a web app called Nell's Wikipedia which behaves as you propose: https://github.com/cscott/nell-wikipedia If you wanted to hack on it, it could use a bit of love. --scott On Jan 23, 2015 7:55 AM, Federico Leva (Nemo) nemow...@gmail.com wrote: Ok these are all planned to be implemented solutions that do not work now You didn't even read, did you? Let me quote: I use this code yes and it works Nemo ___ 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] All Hands On Deck!
Oh what a day! Which began when perforce a visitor from afar began to exhort us to look far afield, to travel and visit learn brand new things, uncover, elicit stories of users far from our homes! And so we set out, bravely to roam: perhaps ten full blocks! We found creatures strange! They all spoke English! The stories exchanged recalled those of family: Mom, Dad, and friends -- it's true, then, we _are_ all the same in the end! Such relief not to grapple with projects baroque, languages strange, or features they wrote. In tune with this sentiment let's celebrate dominance! Hush the less pertinent -- let's not mention those continents. Hurray, we all cheer: Our wiki is strong! Our projects are weak, but shush, sing along: our rivals are fierce, but yet we prevailed; it must be because our PHP scaled! Ignore those naysayers who laugh at our UX And claims by our editors that it obstructs: separate pages for talk, no friends and no chat -- no Serious Software has all of that! Well, enough -- we're not free to change even fonts without acres of missives to agony aunts: let's move next to strategy, where with speeches prolonged new hires will tell us what we got wrong. Three commands we were given: the first, to be punctual. By fiat we've banished the correct but eventual; from now on our code is timely _and_ functional. Our prior disasters are vanished by ritual. The second was novel: exhorted to innovate! Our change-fearing userbase I'm sure will reciprocate. Perhaps we can grow new crops of good editors. New users, new processes, throw off our fetters. Perhaps we need spaces where we can be bold -- it's hard else to see how to do what we're told. The last was to integrate, engage with community; never mind our tall silos and product disunity: we can have orphaned features conflicted teams, clashing visions -- What's key is to synergize! says our stratcom tactician. Community discourse will fix all that ails us: except for those times when instead they've assailed us. Lift a glass to the mission! We'll muddle through fine. We all love each other, but this day's been a grind. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
Petr Bena benap...@gmail.com writes: That suck. Especially with GPRS internet and similar connectivity and it also suck because mobile phones don't even have space for so much data. My idea is to create app similar to kiwix, that would use SQLite DB and using wikipedia API it would (slowly, apache friendly) download contents of any mediawiki installation based on user selection, so that you could download just a 1 page for offline reading, or 1 category. Or 1000 categories. Or precompiled sets of pages created by users (books). You could easily update these using API anytime to latest version. You could get media files for these pages, etc, etc... (You could probably even edit the pages offline, and then update them when you are online, but that is just extra feature) Also see the application that WikiEM (Emergency Medicine) is working on. Dan Ostermayer (CC'd -- Link to original[1]) recently applied for a PEG Grant[2] to continue development on their non-Kiwix alternative for offline Wiki reading[3]. They didn't get a grant, but, from past conversations with Mr. Ostermayer, I understand that content from WikiEM is already being used offline in the Emergency Room and he will continue work on this by getting funding elsewhere. If nothing else, this would probably be a good place to start. Mark. Footnotes: [1] http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/81173 [2] https://meta.wikimedia.org/wiki/Grants:PEG/Offline_MediaWiki_search_for_NASA_and_Medicine [3] https://github.com/ostermayer/offlinexml -- Mark A. Hershberger NicheWork LLC 717-271-1084 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: No more Architecture Committee?
Quim Gil q...@wikimedia.org writes: Can we please discuss the idea of nominating architects per area? Is there any good reason not to do it? There is no good reason not to do this. We should do it. Mark. -- Mark A. Hershberger NicheWork LLC 717-271-1084 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Analytics] Wikimedia referrer policy
Cool. Good idea. /me flags for reading this weekend. On Tue, Jan 20, 2015 at 10:54 AM, Dario Taraborelli dtarabore...@wikimedia.org wrote: I’ve been discussing with the folks at CrossRef (the largest registry of Digital Object Identifiers, think of it as the ICANN of science) how to accurately measure the impact of traffic driven from Wikipedia/Wikimedia to scholarly resources. While digging into their data, we realized that since Wikimedia started the HTTPS switchover and an increasing portion of inbound traffic happens over SSL, Wikimedia sites may have stopped advertising themselves as sources of referred traffic to external sites. While this is a literal implication of HTTPS, it means that Wikimedia's impact on traffic directed to other sites is becoming largely invisible and Wikimedia might be turning into a large source of dark traffic. I wrote a proposal reviewing the CrossRef use case and discussing how other top web properties deal with this issue by adopting a so-called Referrer Policy”: https://meta.wikimedia.org/wiki/Research:Wikimedia_referrer_policy Feedback is welcome on the talk page: https://meta.wikimedia.org/wiki/Research_talk:Wikimedia_referrer_policy Dario ___ Analytics mailing list analyt...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] All Hands On Deck!
On Fri, Jan 23, 2015 at 9:11 AM, littlewmfb...@yandex.com wrote: Oh what a day! Which began when perforce a visitor from afar began to exhort us to look far afield, to travel and visit learn brand new things, uncover, elicit stories of users far from our homes! And so we set out, bravely to roam: perhaps ten full blocks! We found creatures strange! They all spoke English! The stories exchanged recalled those of family: Mom, Dad, and friends -- it's true, then, we _are_ all the same in the end! Such relief not to grapple with projects baroque, languages strange, or features they wrote. In tune with this sentiment let's celebrate dominance! Hush the less pertinent -- let's not mention those continents. Hurray, we all cheer: Our wiki is strong! Our projects are weak, but shush, sing along: our rivals are fierce, but yet we prevailed; it must be because our PHP scaled! Ignore those naysayers who laugh at our UX And claims by our editors that it obstructs: separate pages for talk, no friends and no chat -- no Serious Software has all of that! Well, enough -- we're not free to change even fonts without acres of missives to agony aunts: let's move next to strategy, where with speeches prolonged new hires will tell us what we got wrong. Three commands we were given: the first, to be punctual. By fiat we've banished the correct but eventual; from now on our code is timely _and_ functional. Our prior disasters are vanished by ritual. The second was novel: exhorted to innovate! Our change-fearing userbase I'm sure will reciprocate. Perhaps we can grow new crops of good editors. New users, new processes, throw off our fetters. Perhaps we need spaces where we can be bold -- it's hard else to see how to do what we're told. The last was to integrate, engage with community; never mind our tall silos and product disunity: we can have orphaned features conflicted teams, clashing visions -- What's key is to synergize! says our stratcom tactician. Community discourse will fix all that ails us: except for those times when instead they've assailed us. Lift a glass to the mission! We'll muddle through fine. We all love each other, but this day's been a grind. Madam / Sir, Your lines are fantastically metric With iambs that turn anapestic So it's really a shame that you left out your name 'Cause without one your words are domestic. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New feature in development: collections
Hi Nemo, Great idea. I hope to have at least a bare bones media wiki hub for this project up next week. Best, J On Thu, Jan 22, 2015 at 3:12 AM, Federico Leva (Nemo) nemow...@gmail.com wrote: From https://tools.wmflabs.org/meetbot/wikimedia-office/2015/ wikimedia-office.2015-01-14-21.00.log.html : 21:15:49 Emufarmers Is this collections thing the same as https://www.mediawiki.org/wiki/Mobile_web_projects/Collections_Backend (just came up during the research showcase)? They look related, so I commented on the talk page there. It seems there are parallel discussions in other unknown mailing lists, so it's useful to centralise on the wiki. Nemo ___ 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] Changing contentmodel of pages
On 01/22/2015 10:00 PM, Legoktm wrote: I disagree that we need a editcontentmodel user right. I think all users should be allowed to change the content model of a page (provided they have the right to edit it, etc.). I think that setting a content model different from the namespace's default only makes sense in certain cases. E.g. it may not make sense for schema-tized JSON (whether it's Zero config, EventLogging schema, Wikidata JSON etc.) to be outside its dedicated namespace. It probably doesn't make sense for CSS files or JS files to exist outside of the MediaWiki and User namespaces, and even in those namespaces, the content model should probably match the end of the title. Similarly, dedicated namespaces (e.g. Wikidata's main namespace) should not be able to hold wikitext pages. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikidata search provider for GNOME Shell
On Fri, Jan 23, 2015 at 6:24 AM, Bahodir Mansurov bmansu...@wikimedia.org wrote: I’ve created a GNOME Shell extension that allows the user to search for Wikidata items directly from the shell. Currently you can search for simple things such as “Obama”, “Book”, etc. I plan on adding support for complex queries such as “the population of the earth” which would show the current population of the earth. In the future I also see this extension handle the submission of new entries or editing existing ones. Check it out here [1] if you’re interested. Pull requests are also welcome ;) [1] https://github.com/6ahodir/wikidata-search-provider Thanks, Bahodir! Forwarding to the Wikidata mailing list so they get to see this too. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Input requested about license codes on MediaWiki.org
My RFBot https://www.mediawiki.org/wiki/Project:Requests/User_rights/SamoaBot has been open since 1 month now, with no comments. PS: yes, this is canvassing ;-) Il 18/12/2014 13:19, Ricordisamoa ha scritto: I would appreciate anyone's participation on this proposal https://www.mediawiki.org/wiki/Thread:Template_talk:ExtensionLicense/SPDX_names I've started to use standard identifiers for licenses. Thanks in advance. ___ 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] Idea for new desktop / mobile kiwix like application
Hi, I know most of you hate reinventing a wheel so I first send it here, before I launch that project :) Some of you probably know kiwix - kiwix.org which is offline wikipedia reader. I think the idea of this reader is cool, most of you probably sometimes wanted to access wikipedia while being offline somewhere, but couldn't. Kiwix can help with this, however it has one big problem and solution for it is so complex that it would basically need a rewrite of whole thing. That problem is that you need to download pretty huge file (40+GB) in order to use it for en wikipedia for example. And if you wanted to update those few wikipages you are interested in, to a latest revision, then you again need to download that huge file. That suck. Especially with GPRS internet and similar connectivity and it also suck because mobile phones don't even have space for so much data. My idea is to create app similar to kiwix, that would use SQLite DB and using wikipedia API it would (slowly, apache friendly) download contents of any mediawiki installation based on user selection, so that you could download just a 1 page for offline reading, or 1 category. Or 1000 categories. Or precompiled sets of pages created by users (books). You could easily update these using API anytime to latest version. You could get media files for these pages, etc, etc... (You could probably even edit the pages offline, and then update them when you are online, but that is just extra feature) I think this approach would work much better and it's sad kiwix already doesn't support it. At some point, if it worked I think this new code could be merged back into kiwix, I am going to use C++ in the end, which kiwix uses as well. What do you think about it, is it worth of working on? Is there actually a community of offline wikipedia readers that would appreciate it? Thanks ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
Ok, see my responses bellow. I am interested if there are some users who actually do use offline wikipedia and how would they like this new approach. On Fri, Jan 23, 2015 at 1:34 PM, Federico Leva (Nemo) nemow...@gmail.com wrote: You don't need a new application for this, you just need some upgrades to the ZIM generation pipeline. How about sending patches for https://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner to generate category-based ZIM files and the like? Which is far harder than creating a new application that wouldn't use this ZIM format. So I don't think so. Customisation possibilities used to be better here before https://www.mediawiki.org/wiki/Offline_content_generator was deployed on Wikimedia projects, as ZIM files of few hundreds pages were very easy to make on wiki. Help with the OCG component is also appreciated. Finally, icnremental ZIM updates are an area of ongoing work. You can probably help here as well: https://phabricator.wikimedia.org/T49406#492033 Ok these are all planned to be implemented solutions that do not work now, and maybe will never work. I don't really see any option to use either of these. ZIM format is completely incompatible with what I have proposed. It's one time-baked file that is supposed to be read only, not heavily modified. SQLite format is far better for this design and already exist and works. My goal is to create application that would be naturally extremely small and super easy to use by users who have no understanding of computers and who don't want to download 40gb files in any way. Even if there was a wiki interface that would allow people bake their own ZIM files, I would find it very complex. If you wanted to add 1 page to your collection, wiki would have to generate a new file and you would have to download it again. Using API instead to retrieve data would be more simple. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
Ok these are all planned to be implemented solutions that do not work now You didn't even read, did you? Let me quote: I use this code yes and it works Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Idea for new desktop / mobile kiwix like application
You don't need a new application for this, you just need some upgrades to the ZIM generation pipeline. How about sending patches for https://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner to generate category-based ZIM files and the like? Customisation possibilities used to be better here before https://www.mediawiki.org/wiki/Offline_content_generator was deployed on Wikimedia projects, as ZIM files of few hundreds pages were very easy to make on wiki. Help with the OCG component is also appreciated. Finally, icnremental ZIM updates are an area of ongoing work. You can probably help here as well: https://phabricator.wikimedia.org/T49406#492033 Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: No more Architecture Committee?
For what is worth, nobody at the WMF is suggesting any kind of Architecture Committee discrimination or promotion based on affiliation. Can we please discuss the idea of nominating architects per area? Is there any good reason not to do it? Yesterday I had a chance to speak with Tim, trying to get a specific action for the Engineering Community team in the middle of this dense and complex topic. So here is a simple one: Create a high level overview of the MediaWiki architecture https://phabricator.wikimedia.org/T1287 Your feedback and help is welcome. There are two possible ways of approaching this: 1. experts defining a list of core areas and key extensions 2. non-experts doing the same and upsetting the experts, who step in If 1 doesn't work, I'll advocate for 2, with a risk of starting with the list myself. :) Please don't let me. On Thu, Jan 22, 2015 at 7:31 PM, MZMcBride z...@mzmcbride.com wrote: Mark A. Hershberger wrote: I am not qualified for the ArchCom, but I am familiar with several engineers working in government or running private wiki farms or their own businesses who I think would be qualified. Another qualification I'd look for is substantial Wikimedia community involvement. Architecting requires a very thorough understanding of who you're building for. (I recently raised this same issue on the design mailing list related to editing Wikipedia... I think it's very difficult to build great tools for a community that you're not a part of.) Thankfully, we have lots of good candidates who are both brilliant and understand Wikimedia (Domas, Magnus, and Platonides come to mind off-hand). The trickier part of having non-employees on a committee like this is that other people won't be getting paid to participate and may not have as much time to commit as a result. It's still a bit unclear to me how much work is involved on a weekly basis. If it's just an hour-long IRC session, that's a lot different than needing ten hours or more every week. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
