Wikitech-l January 2014

wikitech-l@lists.wikimedia.org

136 participants
118 discussions

Revamping interwiki prefixes
by This, that and the other 19 Jan '14

19 Jan '14

Sorry about the borked line wrapping in the previous message - I'm resending it so you can read it properly! ---- This is a proposal to try and bring order to the messy area of interwiki linking and interwiki prefixes, particularly for non-WMF users of MediaWiki. At the moment, anyone who installs MediaWiki gets a default interwiki table that is hopelessly out of date. Some of the URLs listed there have seemingly been broken for 7 years [1]. Meanwhile, WMF wikis have access to a nice, updated interwiki map, stored on Meta, that is difficult for anyone else to use. Clearly something needs to be done. What I propose we do to improve the situation is along the lines of bug 58369: 1. Split the existing interwiki map on Meta [2] into a "global interwiki map", located on MediaWiki.org (draft at [3]), and a "WMF-specific interwiki map" on Meta (draft at [4]). Wikimedia-specific interwiki prefixes, like bugzilla:, gerrit:, and irc: would be located in the map on Meta, whereas general-purpose interwikis, like orthodoxwiki: and wikisource: would go to the "global map" at MediaWiki.org. 2. Create a bot, similar to l10n-bot, that periodically updates the default interwiki data in mediawiki/core based on the contents of the global map. (Right now, the default map is duplicated in two different formats [5] [6]which is quite messy.) 3. Write a version of the rebuildInterwiki.php maintenance script [7] that can be bundled with MediaWiki, and which can be run by server admins to pull in new entries to their interwiki table from the global map. This way, fresh installations of MediaWiki get a set of current, useful interwiki prefixes, and they have the ability to pull in updates as required. It also has the benefit of separating out the WMF-specific stuff from the global MediaWiki logic, which is a win for external users of MW. Two other things it would be nice to do: * Define a proper scope for the interwiki map. At the moment it is a bit unclear what should and shouldn't be there. The fact that we currently have a Linux users' group from New Zealand and someone's personal blog on the map suggests the scope of the map have not been well thought out over the years. My suggested criterion at [3] is: "Most well-established and active wikis should have interwiki prefixes, regardless of whether or not they are using MediaWiki software. Sites that are not wikis may be acceptable in some cases, particularly if they are very commonly linked to (e.g. Google, OEIS)." * Take this opportunity to CLEAN UP the global interwiki map! ** Many of the links are long dead. ** Many new wikis have sprung up in the last few years that deserve to be added. ** Broken prefixes can be moved to the WMF-specific map so existing links on WMF sites can be cleaned up and dealt with appropriately. ** We could add API URLs to fill the iw_api column in the database (currently empty by default). I'm interested to hear your thoughts on these ideas. Sorry for the long message, but I really think this topic has been neglected for such a long time. TTO ---- PS. I am aware of an RFC on MediaWiki.org relating to this, but I can't see that gaining traction any time soon. This proposal would be a more light-weight way of dealing with the problem at hand. [1] https://gerrit.wikimedia.org/r/#/c/84303/ [2] https://meta.wikimedia.org/wiki/Interwiki_map [3] https://www.mediawiki.org/wiki/User:This,_that_and_the_other/Interwiki_map [4] https://meta.wikimedia.org/wiki/User:This,_that_and_the_other/Local_interwi… [5] http://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/maintenance%2Fint… [6] http://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/maintenance%2Fint… [7] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikimediaMaintenanc…

7 8

On-wiki configuration RfCs (was: Proposed Program Architecture Summit 2014)
by legoktm 19 Jan '14

19 Jan '14

On Thu, Jan 16, 2014 at 2:52 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: > Let's put that number at 95% :-) I don't want to commit the group to > anything; it's at the top of the short list, but you never know where > people will want to take the conversation. > > Legoktm, the thing you could do to push it over the top is to write up > a summary as you see it of the various positions, and post it to this > list. Ideally, you would also publish it as a subpage of the > Architecture Summit 2014 page, similar to how some of the others are > (e.g. HTML templating[1]) Even if we don't get to it at the summit, > it still will be a very useful backgrounder to have. Is that > something you'd be willing to chip in with? Sure, I created <https://www.mediawiki.org/wiki/Architecture_Summit_2014/Configuration>, and solicited feedback from ^demon and Yurik. I've included it below for ease: MediaWiki is currently configured via a series of global variables that must be set in a PHP file by a user with file system access. This cluster of RfCs intends to allow the wiki to be configured using an on-wiki mechanism. Some of the motivations behind this can be found in the first RfC[1]. The first two RfCs, "Configuration database"[2], and "Configuration database 2"[3] discuss storing configuration parameters in a database table, while "Json Config pages in wiki"[4] discusses using a JSON ContentHandler to store configuration options in a wiki page. Some of these features have already been implemented in extensions: Configure provides basic on-wiki configuration functionality, and CentralAuth allows custom global user groups to be created on-wiki. The EventLogging, UploadWizard, and ZeroRatedMobileAccess extensions all currently store configuration options in JSON formatted pages. See also: bug 26992[5], "Implement configuration database aka configuration management aka no shell excuse (tracking)" [1] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database#… [2] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database [3] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2 [4] https://www.mediawiki.org/wiki/Requests_for_comment/Json_Config_pages_in_wi… [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=26992 -- Legoktm

1 0

Review Milestone reached
by bawolff 18 Jan '14

18 Jan '14

Aaron Schulz has become the first person to have approved (+2'ed) >= 1000 patchsets to mediawiki core [1]. I thought this nice round number deserved a note, and a "good job". Thank you Aaron for all your hard work reviewing things. --bawolff [1] https://toolserver.org/~nemobis/crstats/core.txt

4 3

Contributing to Wikimedia as Web Developer and Systems Administrator
by Nitin Agarwal 18 Jan '14

18 Jan '14

Hi, Here, its Nitin Agarwal, Software Developer and Programmer. I am currently pursuing Computer Science and Engineering at International Institute of Information Technology, INDIA. I would like to Wikimedia as Web Developer and Systems Administrator projects. I have gone through the https://www.mediawiki.org/wiki/Starter_kitand installed and configured mediawiki on my machine running at localhost. I would like to work on the ongoing project works of Wikimedia and carry on with the project through Gsoc 2014 and afterwards, become a regular contributor to Wikimedia. One can see my username as Wikimedia over here : https://www.mediawiki.org/wiki/User:Nitinagarwal3006 Github : *https://github.com/NitinAgarwal <https://github.com/NitinAgarwal>* IRC : nitinagarwal3006 -- *Nitin Agarwal* Website : www.nitinagarwal.in

1 0

Dynamic unit conversion
by Petr Bena 17 Jan '14

17 Jan '14

.Hi, There are many articles on wikipedia that contain different units. Some use cm, that are common in europe, other use inches that are more widely used in US, same with other unit types. I think it would be cool if an extension was created which would allow everyone to specify what units they prefer, and the values in articles would be converted automatically based on preference. For example you would say the object has width of {{unit|cm=20}} and people who prefer cm would see 20 cm in article text, but people who prefer inches would see 7.87 inch. This could be even based on geolocation for IP users What do you think?

8 15

Tampa datacenter issues
by Erik Moeller 17 Jan '14

17 Jan '14

Hi all, We had a fibre cut of our connection to our Tampa DC this morning. ETA of a fix is still pending, but the cuts have been located and crews are being dispatched. Meanwhile public traffic is being rerouted via the public Internet, so most services should be reachable. Tampa is our secondary DC which we're decommissioning, so there was no impact on our main sites. Impacted temporarily were: inbound Wikimedia.org email, Bugzilla, Labs. Fundraising is still impacted, but shouldn't be (we're debugging). Thanks to the ops team for their quick response. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

3 3

Deployment and Roadmap highlights - week of January 20th
by Greg Grossmeier 17 Jan '14

17 Jan '14

Hello and welcome to the latest edition of the deployment and roadmap highlights. Full up-to-date schedule, as always, can be found online at: <https://wikitech.wikimedia.org/wiki/Deployments> == Throughout the week == * The Technical Operations team will be bringing the west coast caching center ("ULSFO") online (again, after a failed first attempt due to connectivity limitations). This work will happen throughout the week. * On Thursday and Friday there is the MediaWiki Architecture Summit in San Francisco. See: https://www.mediawiki.org/wiki/Architecture_Summit_2014 * Due to the US public holiday on Monday (Martin Luther King Jr Day) and the Architecture Summit, the week of the 20th will be a low/no deploy week. As such, the only things on the calendar are placeholders for "Lightning Deploys" on Tues, Wed, and Thurs (Pacific time). Let me know if you have any questions, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Revamping interwiki prefixes
by This, that and the other 17 Jan '14

17 Jan '14

Long message coming up... please be brave and take a look :) This is a proposal to try and bring order to the messy area of interwiki linking and interwiki prefixes, particularly for non-WMF users of MediaWiki. At the moment, anyone who installs MediaWiki gets a default interwiki table that is hopelessly out of date. Some of the URLs listed there have seemingly been broken for 7 years [1]. Meanwhile, WMF wikis have access to a nice, updated interwiki map, stored on Meta, that is difficult for anyone else to use. Clearly something needs to be done to sort this out. What I propose we do to improve the situation is along the lines of bug 58369: 1. Split the existing interwiki map on Meta [2] into a "global interwiki map", located on MediaWiki.org (draft at [3]), and a "WMF-specific interwiki map" on Meta (draft at [4]). Wikimedia-specific interwiki prefixes, like bugzilla:, gerrit:, and irc: would be located in the map on Meta, whereas general-purpose interwikis, like orthodoxwiki: and wikisource: would go to the "global map" at MediaWiki.org. 2. Create a bot, similar to l10n-bot, that periodically updates the default interwiki data in mediawiki/core based on the contents of the global map. (Right now, the default map is duplicated in two different formats [5] [6] which is quite messy.) 3. Write a version of the rebuildInterwiki.php maintenance script [7] that can be bundled with MediaWiki, and which can be run by server admins to pull in new entries to their interwiki table from the global map. This way, fresh installations of MediaWiki get a set of current, useful interwiki prefixes, and they have the ability to pull in updates as required. It also has the benefit of separating out the WMF-specific stuff from the global MediaWiki logic, which is a win for external users of MW. Two other things it would be nice to do: * Define a proper scope for the interwiki map. At the moment it is a bit unclear what should and shouldn't be there. The fact that we currently have a Linux users' group from New Zealand and someone's personal blog on the map suggests the scope of the map have not been well thought out over the years. My suggested criterion at [3] is: "Most well-established and active wikis should have interwiki prefixes, regardless of whether or not they are using MediaWiki software. Sites that are not wikis may be acceptable in some cases, particularly if they are very commonly linked to (e.g. Google, OEIS)." * Take this opportunity to CLEAN UP the global interwiki map! ** Many of the links are long dead. ** Many new wikis have sprung up in the last few years that deserve to be added. ** Broken prefixes can be moved to the WMF-specific map so existing links on WMF sites can be cleaned up and dealt with appropriately. ** We could add API URLs to fill the iw_api column in the database (currently empty by default). I'm interested to hear your thoughts on these ideas. Sorry for the long message, but I really think this topic has been neglected for such a long time. TTO ---- PS. I am aware of an RFC on MediaWiki.org relating to this, but I can't see that gaining traction any time soon. This proposal would be a more light-weight way of dealing with the problem at hand. [1] https://gerrit.wikimedia.org/r/#/c/84303/ [2] https://meta.wikimedia.org/wiki/Interwiki_map [3] https://www.mediawiki.org/wiki/User:This,_that_and_the_other/Interwiki_map [4] https://meta.wikimedia.org/wiki/User:This,_that_and_the_other/Local_interwi… [5] http://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/maintenance%2Fint… [6] http://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/maintenance%2Fint… [7] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikimediaMaintenanc…

6 10

Proposed Program Architecture Summit 2014
by Diederik van Liere 16 Jan '14

16 Jan '14

Heya, The Program Committee for the Architecture Summit has published a proposed program: https://www.mediawiki.org/wiki/Architecture_Summit_2014 Highlights of the Program: 1) We have tried to incorporate flexibility into the program by allowing 4 unconference break-out slots, 1 open plenary session and a daily ‘agenda bashing’ session to make adjustments to the program if the need arises. 2) There are 3 plenary sessions: HTML Templating ( https://www.mediawiki.org/wiki/Architecture_Summit_2014/HTML_templating), Service Oriented Architecture ( https://www.mediawiki.org/wiki/Architecture_Summit_2014/Service-oriented_ar…) and one open slot. Possible candidates for the open session include Performance and UI styling but this will be decided during the Summit. The short list will include the higher vote-getters in the straw poll, so if there’s one of the clusters you strongly feel should be part of the program, now is your time to make that case. 3) There are 6 breakout sessions: * 2 planned: UI styling ( https://www.mediawiki.org/wiki/Architecture_Summit_2014/UI_styling) and Storage Services ( https://www.mediawiki.org/wiki/Architecture_Summit_2014/Storage_services) * 4 unconference slots There will be a round of Lightning Talks at the beginning of the plenary session after the breakout session to summarize what happened by answering the following questions: a) What did you try to achieve? b) What did you decide? c) What are the next steps? 4) Architecture Panel and Value discussion. This is a plenary session for the architects to share what they value in good architecture, as well as talk about how they see the architecture of MediaWiki evolving, and what role people other than our historical core group of three have to play in the process. During this session, we hope to at least answer some of the questions outlined in the recent discussion of the RFC process[1] 5) RFC roulette: a one hour closing session for RFC’s that have not been in the spotlight during the Summit and where the next step can be decided. This is intended to be fast paced and slightly chaotic. If you would like to hear what’s next for your RFC please participate with the roulette by adding your name to https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_roulette What does the Program Committee expect from summit participants? a) If you are a participant, please familiarize yourself with the latest version of the RFC’s that you care about. b) If you are an author of an RFC that is scheduled in a plenary session, please start preparing in collaboration with the other authors from the same session on a short slidedeck that summarizes all the different RFC’s. One slide that could be really useful is to have a matrix that highlights key differences between alternative / competing proposals. Diederik will contact the folks who are invited for the plenary session to help coordinate and organize. c) If you are an author of an RFC that is scheduled in a breakout session, please create maximum 3 slides that summarize your RFC and think about what you want to get out of your session. The slides are optional, but the requisite level of preparation is not. d) If you want to run an unconference slot then start thinking about a theme and possible co-organizers. It’s okay to use an existing RFC cluster. Two quick final notes: The Program has been created using the input from the straw poll ( https://www.mediawiki.org/wiki/Architecture_Summit_2014/Straw_poll), input from the Program Committee and input from the Engineering Community Team. To see which RFC’s compose a cluster please have a look at https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters Looking forward to your feedback! Best regards, The Program Committee [1] Discussion of the RFC process: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Process#

3 3

L3 outage reports at Equinix Ashburn
by Jay Ashworth 16 Jan '14

16 Jan '14

That's where we are, right? Some people on outages are reporting no-light on on-campus fibers*; if we see an uptick in problem reports this morning, that might be why. Cheers, -- jra * specifically DC2 to DC5 -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

1 0

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l January 2014