Wikitech-l November 2015

wikitech-l@lists.wikimedia.org

118 participants
109 discussions

Skinning tutorial
by Isarra Yos 12 Nov '15

12 Nov '15

As a bit of a follow up to the talk I did last week, I wrote up a tutorial on-wiki how to make a skin: https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin The plan is to eventually replace Manual:Skinning with that and some subpages with specific info, but if anyone wants to run through now, see if it's useful, try it out, see if anything is missing or wrong, I'd appreciate the help making it better. -I ps - Yes, I may have read motherfuckingwebsite.com a few too many times before writing that up. I, uh, sort of apologise.

3 7

RFC: make Parser::getTargetLanguage aware of multilingual wikis
by Daniel Kinzler 11 Nov '15

11 Nov '15

Hi all! Tomorrow's RFC discussion[1] on IRC (22:00 UTC at #wikimedia-office) will be about my proposal to use Parser::getTargetLanguage to allow wiki pages to be generated in different languages depending on the user's interface language [2]. I would like to take this opportunity to gather some input beforehand about how we can improve MediaWiki's support for multilingual wikis on the parser level. In particular, I'm interested to learn about the implications my proposal has for the Translate extension, the templates currently used on commons, sites that use automatic transliteration, etc. Some context: Currently, MediaWiki doesn't really have a concept of multilingual content. But some wikis, like Commons and Wikidata, show page content in the user's language, using a veriety hacks implemented by extensions such as Translate and Wikibase. It would be nice to make MediaWiki aware of multilingual content, and add some limited suppor for this to core. Some bits and pieces already exist, but that don't quite work for what we need. One issue is that parser functions (and Lua code) have no good way to know what the target language for the current page rendering is. Both ParserOptions and Parser have a getTargetLanguage method, but this is used *only* when displaying system messages in a different language on pages like MediaWiki:Foo/fr. I propose to change core so it will set the target language in the parser options to the user language on wikis/namespaces/pages marked as multilingual. This would allow parser functions and Lua libraries to generate content in the desired target language. There is another related method, which I propose to drop, or at least move: Title::getDisplayLanguage (resp ContentHandler::getDisplayLanguage). This seems to be used by wikis that apply transliteration to page content, but it's a but the semantics ar ea it unclear. I propose to drop this in favor of ParserOptions::getTargetLanguage, since the display language is not a property of the page, but an option defined for the rendering of the page. Another related issue is anonymous browsing of multi-lingual content. This will either go past the web cache layer (as is currently done on commons), or it's simply not possible (as currently on wikidata). I have put up an RFC for that as well[3], to be discussed at a different time. [1] <https://phabricator.wikimedia.org/E89> [2] <https://phabricator.wikimedia.org/T114640> [3] <https://phabricator.wikimedia.org/T114662> -- Daniel Kinzler

5 8

Transitioning wikistats pageview reports to use new pageview definition
by Nuria Ruiz 11 Nov '15

11 Nov '15

Hello! The analytics team wishes to announce that we have finally transitioned several of the pageview reports in stats.wikimedia.org to the new pageview definition [1]. This means that we should no longer have two conflicting sources of pageview numbers. While we are not not fully done transitioning pageview reports we feel this is an important enough milestone that warrants some communication. BIG Thanks to Erik Z. for his work on this project. Please take a look at a report using the new definition (a banner is present when report has been updated) http://stats.wikimedia.org/EN/TablesPageViewsMonthlyCombined.htm Thanks, Nuria [1] https://meta.wikimedia.org/wiki/Research:Page_view

3 2

Concentrate content related error messages in one place
by Purodha Blissenbach 11 Nov '15

11 Nov '15

Discussions on "Figure out what to do with the table of contents" at <https://phabricator.wikimedia.org/T114057>. and the "balanced templates" RFC inspired me to suggest: Concentrate content related error messages in one place <https://phabricator.wikimedia.org/T118377> Looking forward to your comments. Purodha

1 0

"Try the free Wikipedia app" banners
by Ori Livneh 11 Nov '15

11 Nov '15

We appear to be running a banner campaign on the mobile web site, driving people to download the mobile app: https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_2 https://en.m.wikipedia.org/wiki/?banner=Aug2015_app_banner_1 Campaign definition: https://meta.wikimedia.org/w/index.php?title=Special:CentralNotice&subactio… This isn't cool. This isn't us. We don't drive people from an open platform to a closed one.

14 27

Summit proposal: Turning the Table of Contents into a discrete object
by Isarra Yos 10 Nov '15

10 Nov '15

Hi! I would like to turn the mw ToC into a discrete object within the codebase. Write a ToC class and pull all the random building parts out of the parser and five levels of pageoutput, and make it stop messing up the page caching and stuff. Make this class a thing, separate from the content itself, that can appear on the page or be toggled or messed with or added to or moved or whatever by extensions. I have a proposal about this for the developers summit which is about as specific: https://phabricator.wikimedia.org/T114057 Please come discuss. Would this affect what you're doing in a good or bad way? What do we know of that this should support at present? What would we, as developers or whatever the buckets, want out of it? Also is this the sort of thing you normally use an RfC for? I'm a designer so I'm just asking questions and soliciting stories and all that before I go trying to do designy stuff on the mw backend, but maybe that's not really the way to do this here. -I

4 4

people.wikimedia.org moved, access for all shell users
by Daniel Zahn 10 Nov '15

10 Nov '15

Hi, crossposting from the operations list, so that all shell users see it. this is to let you know that the service https://people.wikimedia.org has moved to a new backend server. From terbium to "rutherfordium.eqiad.wmnet", which is a ganeti VM. Also, all shelll users have access now. We don't limit it to deployers anymore and this service is now completely separate from any mediawiki maintenance work that is happening on terbium, and terbium can be upgraded to hhvm. If you are an existing user: Please just switch from using terbium.eqiad.wmnet to the new backend rutherfordium.eqiad.wmnet. All files have been copied with rsync from terbium, you should not have to copy anything manually, and all URLs should still work. You just have to connect to the new place to update files. Both home directories are backed up in Bacula. If you did not have access to this before, but have any kind of shell access: Now you also have access to people.wikimedia.org and can have an URL like https://people.wikimedia.org/~youruser. (as opposed to just deployers having this feature in the past). To upload files copy them (with scp) to rutherfordium.eqiad.wmnet into a directory called "public_html". If that doesn't exist yet, simply create it with "mkdir public_html". Files in that directory will be publicly accessible as https://people.wikimedia.org/~youruser/yourfile. I also added a message to SAL and will update https://wikitech.wikimedia.org/wiki/People.wikimedia.org right now. -- Daniel Zahn <dzahn(a)wikimedia.org> Operations Engineer

1 0

Forking, branching, merging, and drafts on Wikipedia
by C. Scott Ananian 09 Nov '15

09 Nov '15

There is a proposal for the upcoming Mediawiki Dev Summit to get us "unstuck" on support for non-linear revision histories in Wikipedia. This would include support for "saved drafts" of wikipedia edits and offline editing support, as well as a more permissive/friendly 'fork first' model of article collaboration. I outlined some proposed summit goals for the topic, but it needs a bit of help if it is going to make the cut for inclusion. I hope interested folks will weigh in with some comments on https://phabricator.wikimedia.org/T113004 --- perhaps suggesting specific "next step" projects, for instance. Thanks for your help. --scott -- (http://cscott.net)

4 4

Parsoid still doesn't love me
by Ricordisamoa 09 Nov '15

09 Nov '15

What if I need to get all revisions (~2000) of a page in Parsoid HTML5? The prop=revisions API (in batches of 50) with mwparserfromhell is much quicker. And what about ~400 revisions from a wiki without Parsoid/RESTBase? I would use /transform/wikitext/to/html then. Thanks in advance.

6 9

Community Tech: October report
by Danny Horn 07 Nov '15

07 Nov '15

In the Community Tech team, we're constantly striving to make the world better by creating helpful things and fixing unhelpful things. We're basically superheroes, and we wear capes at all times. Here's what we've been up to this month. * We built a new Special:GadgetUsage report that's live on all wikis; it lists gadgets used on the wiki, ordered by the number of users. Not to be clickbait or anything, but THE RESULTS WILL SHOCK YOU. Check it out at https://commons.wikimedia.org/wiki/Special:GadgetUsage or your own favorite wiki. * HotCat is one of the most popular gadgets -- see: GadgetUsage report above -- which helps people remove, change and add categories. We fixed HotCat on over 100 wikis where it was broken, including Wikipedias in Egyptian Arabic, Ripuarian, Buginese and Navajo, and five projects in Farsi -- Wikinews, Wikiquote, Wikisource, Wikivoyage and Wiktionary. You're welcome, Farsi! (More info on https://en.wikipedia.org/wiki/Wikipedia:HotCat ) * CitationBot is a combination tool/on-wiki gadget that helps to expand incomplete citations. We got it running again after the https change, updated it, and fixed some outstanding bugs, including handling multiple author names. (See http://tools.wmflabs.org/citations/doibot.html for more info.) * We also built a prototype of a new tool called RevisionSlider, which helps editors navigate through diff pages without having to go back and forth to the history page. The prototype is live now on test.wp, and we'd love to get your feedback -- visit https://meta.wikimedia.org/wiki/Community_Tech/RevisionSlider Coming up in November: * We're starting a big cross-project Community Wishlist Survey on November 9th, inviting contributors from any wiki to propose and vote on the features and fixes they'd like our team to work on. The survey page is on Meta, at https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey -- please join us there on Monday to add your proposals. * While that's going on, we're currently considering work in a few different areas, including completing Gadgets 2.0 and building some modules to help WikiProjects. You can keep track of what we're working on by watching Community Tech/News on Meta: https://meta.wikimedia.org/wiki/Community_Tech/News -- and feel free to leave questions or comments on the talk page. Thanks! DannyH (WMF) Community Tech

5 5

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

2025

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 November 2015