Wikitech-l December 2014

wikitech-l@lists.wikimedia.org

88 participants
95 discussions

[BREAKING CHANGE] Plans to move Cite configuration from wikitext messages to CSS styles
by Marc Ordinas i Llopis 14 Jan '15

14 Jan '15

All, TL;DR: * References made using Cite will be configurable with a different system * New approach being prototyped in Parsoid's native implementation of the Cite extension The Cite extension[0], which provides in-page footnotes is a crucial part of how many of us use wikis, especially for Wikipedias. However, it was written a very long time ago, even by MediaWiki standards, and in its creation, we made some design choices which made sense at the time, but don't work very well for us anymore. As CSS has gotten more features, and those features have become more reliably implemented in modern browsers, we have more choices now. One of the great things about the Cite extension is its flexibility, such as each wiki being able to choose how the footnotes display to readers. Unfortunately, the means by which this flexibility is provided is currently done through a series of 14 different MediaWiki namespace wikitext messages which are interpreted to create the HTML to display to the user. This has a number of disadvantages. Most wikis use the default values (and even very experienced users are probably unaware of how it works or even that it can be changed). Because they are implemented in wikitext, per-user changes such as with a gadget or a user script aren't possible to do neatly (and instead need JavaScript to re-write the content, which is slower and more complex), and changes take up to 30 days to be visible to anonymous users whilst they wait for the cache to change. Due to how MediaWiki's messages system works, changes to the display styles need to be copied into each of the ~300 display languages for users, else those users with different languages will see different reference styles on the same page. Any system that wishes to display MediaWiki references has to implement most of MediaWiki just to format these references correctly. To fix this, the Parsoid and editing teams are proposing to replace the current way to configure the Cite extension with some CSS rules, which will solve these issues. Experimenting will be much easier to do on a per-user or gadget-basis in advance of making larger changes. Styles will be shared by all users of the wiki, regardless of their preferred language, and complicated user scripts or gadgets that slow down the system will not be needed to change the style. Changes will be instant for all users, even those logged out, and non-MediaWIki users can use styles to correctly and consistently display references. A currently-under-review patch[1] for Parsoid demonstrates use of CSS to do variations found on enwiki, eswiki, and fawiki. We think that this approach will allow us to match each of the current styles used on Wikimedia wikis. If there is any variation (currently in use) that we should experiment with, please let us know. We plan to continue to prototype this approach in Parsoid and work through any rendering issues. Given that most Wikimedia wikis don't customize the extension, for most Wikimedia wikis, we expect this will work with the basic configuration (and for a few Wikipedias which need different configuration, we will add styling). Once we port this solution over to the master branch of the Cite extension, this will be a breaking configuration change in the MediaWiki 1.25 release. If you have a gadget or user script which changes how references appear or relies on something local to your wikis, you may need to tweak it. Given that older browsers (IE6 and IE7 most notably) may not implement the CSS features that we need for this, we don't plan to rely solely on a CSS-based approach. Our current approach is to use a default bare HTML style on browsers that don't support content generation (like ::after and counters). We invite your comments, feedback, and help with this. Thanks, Marc, Parsoid and Editing teams. [0] – https://www.mediawiki.org/wiki/Extension:Cite [1] – https://gerrit.wikimedia.org/r/#/c/170936/

6 10

OOjs and OOjs UI for on-wiki gadgets
by Ricordisamoa 13 Jan '15

13 Jan '15

Are they ready for use? (When) will jQuery UI be phased out?

2 3

A new extension of content tree about Wikipedia
by Eallan 09 Jan '15

09 Jan '15

Hi all! I am thinking about a new idea about a content tree extension of web/desktop/computer Wiki. When I use mobile phone to access website of Wikipedia, I can fold and unfold a content item of the content tree. That's very convenient. However, when I use computer to access Wiki, there is no such feature, I can not fold or unfold a content item. So shall we add this feature from mobile Wiki to the web/computer Wiki? In other words, let the user able to fold and unfold any content item at any level of the content tree. For example, I search Taipei, I get 1. History, 2. Geography, 1.1 First settlements, and 1.2 Japaneses rule ect. So I would like to able to unfold 1. History, and 1.1 First settlements, or I just unfold 1. History and fold 1.1 First Settlements to see 1.2 Japanese rule which is unfolded. So I would like to fold and unfold any level content items to further the visit quality. The mobile side wiki also can improve, since it can only fold and unfold the first level content item. Also,add a go-back button which let the user go back to the content tree from any content item of any level in the content tree. Eallan

9 16

MediaWiki Developer Summit 2015 schedule & instructions
by Quim Gil 07 Jan '15

07 Jan '15

A draft version of the MediaWiki Developer Summit 2015 (San Francisco, January 26-27) is available at https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Schedule You will see some slots pre-scheduled for three main topics: Mobile, Editing, and Service Oriented Architecture. There are some pre-scheduled sessions proposed by the Architecture Committee and the Product team, plus the opening and wrap-up sessions. There are many slots available, and at this point almost everything is flexible and negotiable. To book your session, check https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#How_to_sched… As an experiment, we are linking all sessions to a corresponding Phabricator task. The goal is to ease documentation and discussion before and after the summit, linking each session to related tasks and projects. This is also a way to add the preparation of the session to your personal and team backlogs. Allocate time to prepare your sessions, and encourage discussion and collaboration before and after the event. Let's make the most out of this unique MediaWiki gathering! -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 2

Tech Talk: API Client Libraries: January 6th
by Rachel Farrand 06 Jan '15

06 Jan '15

Please join us for the following tech talk: *Tech Talk**:* A developer's-eye view of API client libraries: how to choose them, how to make them, how to make them better *Presenter:* Frances Hocutt *Date:* January 6 *Time:* 1830 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=tech+talk%3A+API+c…> Link to live YouTube stream <http://www.youtube.com/watch?v=hz__duVeaWY> *IRC channel for questions/discussion:* #wikimedia-office Google+ page <https://plus.google.com/u/0/b/103470172168784626509/events/c8fnclmkeam2gbrn…>, another place for questions *Talk description: *This talk will cover why developers do (and don't) use any of the wide variety of client libraries available to get and post data through the MediaWiki API. We'll talk about writing tools with an eye to developer experience, go through the "gold standard" for MediaWiki API client libraries (https://www.mediawiki.org/wiki/API:Client_code/Gold_standard) and the thinking behind it, and share some of the resources available for both library writers and library users. If you write or maintain an API client library, you'll learn about what you can do to help your library get out of the way and let developers who work with it spend their mental energy on putting together exciting projects, not on fighting with tools. If you work with the MediaWiki API (write bots, do research, maintain wikis), you'll learn what to consider when you're choosing a framework for your project. Either way, you'll start to appreciate all the factors beyond a library's code that make the difference between fun and easy development and a frustrating slog.

1 1

Graphviz extension
by Yury Katkov 04 Jan '15

04 Jan '15

Hi everyone! I've seen that Graphviz extension is being developed again! The old version could parse the following graph: <graphviz> digraph W { rankdir = LR ; node[fontsize=10, fontcolor="blue", shape="none", style=""] ; node [URL="/mw/index.php?title=\N"] ; "User:MediaWiki default" "User:MediaWiki default" [tooltip="MediaWiki default"] ; "User:MediaWiki default" [fontcolor="#BA0000"]; "User:Us0" "User:Us0" [tooltip="Us0"] ; "User:Us0" [fontcolor="#BA0000"]; "User:Admin" "User:Admin" [tooltip="Admin"] ; "User:Admin" [fontcolor="#BA0000"]; "User:MediaWiki default" -> "Main Page" [ penwidth=2.0968239556951 label=1] ; "User:Us0" -> "Main Page" [ penwidth=10.340079843406 label=6] ; "User:Admin" -> "Main Page" [ penwidth=5.7720138182848 label=3] ;}</graphviz> It seems that the new version doesn't understand any parameters except the -> links. I'm having an error: Error: No valid link was found at the end of line 2. At Imagemap_body.php I see a lot of madness going on: regular expressions and other horrible things. It seems that now Graphviz extension supports only a little fraction of the dot language. Is that because of Imagemap? Cheers, ----- Yury Katkov

2 2

links to non-existent #sections
by Amir E. Aharoni 04 Jan '15

04 Jan '15

Hallo, If I link to a section (anchor) that doesn't exist, for example [[Valentina Tereshkova#There's no such section]], the link will still be blue. Did anybody ever consider showing them in a different color, for example? I cannot find anything like that in Phabricator. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

4 5

Need a little help with a Phabricator email
by Strainu 31 Dec '14

31 Dec '14

Hi, I've received the following email from Phabricator for a commit that seems to have been made 3-4 years ago. Trying to access the commit, I get "Permission denied" My questions are: 1. What is Diffusion? 2. Why can't I see the commit? 3. Why did I recieve this email, even though I am not allowed to see the commit? Thanks and a happy new year, Strainu ----- Mesaj original ----- De la: Strainu <no-reply(a)phabricator.wikimedia.org> Către: Cc: Trimis: Miercuri, 31 Decembrie 2014 20:25:14 Subiect: [Diffusion] [Committed] rTHER576d6ad454cb: Adding flickrripper_strainu.py (upload bot for Flickr groups of WLM2011 Strainu committed rTHER576d6ad454cb: Adding flickrripper_strainu.py (upload bot for Flickr groups of WLM2011 (authored by Strainu). Adding flickrripper_strainu.py (upload bot for Flickr groups of WLM2011 git-svn-id: https://svn.toolserver.org/svnroot/p_erfgoed@395 3e45a915-b2e0-c146-c98e-857251466b57 AFFECTED FILES USERS Strainu (Author) COMMIT https://phabricator.wikimedia.org/rTHER576d6ad454cb EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Strainu

2 2

broken user scripts getting in the way of other features
by Amir E. Aharoni 31 Dec '14

31 Dec '14

Hallo, I am a bit of advocate for VisualEditor in my home Wikipedia (Hebrew), and I ran into a user with a curious problem: He is an experienced editor, and he was positive about trying to edit with VE, but it didn't work for him. After a bit of poking around I found that he has a common.js in his user space that had a syntax error. He probably tried to add some user script once, did it incorrectly, and didn't bother to continue. This didn't break any other JS-based features, at least not in a way that he noticed, but it did break VE. It's possible that he's not the only one. Is there a way to lint all the user-space JS pages to see that user don't break their own environments? Even a basic syntax check would be nice. One could say that users should be responsible for their user spaces, but in practice some users just copy some code without understanding what they did, and this can help them get rid of cruft. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

2 1

RFC: Guidelines for extracting, publishing and managing libraries
by Bryan Davis 30 Dec '14

30 Dec '14

I have posted a new RFC [0] related to the "librarization" project [1] that Kunal, Chad, Aaron, myself and others have been working on for the last quarter. The intent of the RFC is to establish a reasonable set of guidelines for how to manage a library project. The core idea behind the librarization project and this RFC is that MediaWiki will benefit from a more strict separation of components and many of those components solve general programming problems that will also be of interest to non-MediaWiki developers. The project has done some initial work to pull CSSJanus and CDB out of MediaWiki and make them available as Composer managed libraries. We then added these libraries as requirements in the MediaWiki composer.json manifest and updated mediawiki/vendor.git per the Composer managed libraries RFC [2]. The new RFC attempts to provide a roadmap for additional projects undertaken by the WikiMedia community in this direction. The current draft focuses mainly on the infrastructure that a new library project will need to use (git hosting, code review, issue tracking) and the policy decisions that need to be made (license, code style). There is some discussion of the actual mechanics of extracting a library but they are a bit handwavy prior to the point of having the classes that are to be extracted isolated in the includes/libs directory. I'd appreciate feedback on the RFC either here on the mailing list or on the RFC's talk page. I'm especially interested to hear constructive input on which sections may be too proscriptive and which may err in the opposite direction and be too loose. [0]: https://www.mediawiki.org/wiki/Requests_for_comment/Guidelines_for_extracti… [1]: https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki [2]: https://www.mediawiki.org/wiki/Requests_for_comment/Composer_managed_librar… Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
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 December 2014