Wikitech-l December 2014

wikitech-l@lists.wikimedia.org

88 participants
99 discussions

Our CAPTCHA is very unfriendly
by Jon Harald Søby 17 Mar '15

17 Mar '15

Hi all, My apologies if this is the wrong place to start a discussion on this, but it's a better place than nowhere. I recently took part in two very different Wikipedia workshops -- one in Uganda for schoolchildren aged 14-17, and one Bodø, Norway, for GLAM people aged 35-55. One glaringly obvious barrier of entry that was common for both groups is that the CAPTCHA we use is too freaking hard. The main concern is obviously that it is really hard to read, but there are also some other issues, namely that all the fields in the user registration form (except for the username) are wiped if you enter the CAPTCHA incorrectly. So when you make a mistake, not only do you have to re-type a whole new CAPTCHA (where you may make another mistake), you also have to re-type the password twice *and* your e-mail address. This takes a long time, especially if you're not a fast typer (which was the case for the first group), or if you are on a tablet or phone (which was the case for some in the second group). So I would like to start a discussion about changing to a CAPTCHA that is more user-friendly, and hopefully one that isn't as English/Latin-alphabet-centric as the one we currently use. If Ugandan children and old Norwegian people, which all use the Latin alphabet, have such problems deciphering the CAPTCHA, what about people speaking languages that don't use the Latin alphabet? I would prefer something more simplistic, like some sort of math or image-based CAPTCHA, instead of the current CAPTCHA we use. -- mvh Jon Harald Søby <http://meta.wikimedia.org/wiki/User:Jon_Harald_S%C3%B8by>

28 68

Tech Talk: What's New with MediaWiki-Vagrant?: Simple Use Cases and Beyond: November 25
by Rachel Farrand 01 Mar '15

01 Mar '15

Please join us for the following tech talk: *Tech Talk**:* What's New with MediaWiki-Vagrant?: Simple Use Cases and Beyond *Presenter:* Bryan Davis & Dan Duvall *Date:* November 25th *Time:* 1830 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=What%27s+New+with+…> Link to live YouTube stream <http://www.youtube.com/watch?v=I66xR-fq2O8> *IRC channel for questions/discussion:* #wikimedia-office Google+ page <http://www.youtube.com/watch?v=I66xR-fq2O8>, another place for questions *Talk description:*We'll start off by giving a brief refresher on how MW-Vagrant works and how it differs from stock Vagrant. Next, we'll showcase some of the newest and most useful features of MWV such as multi-wiki support, SSH/HTTP sharing, Labs integration, advanced customization using Hiera and local roles. Finally, we'd like to show how MWV can be useful in test-driven development by demonstrating how to run unit and browser tests. The last 15 minutes will be reserved for Q/A. == Outline (WIP) == * (10 minutes) What is Vagrant, MediaWiki-Vagrant, Puppet (dan + bryan) * (15 minutes) Local customizations (bryan) * (15 minutes) Running unit tests and browser tests under MW-V (dan) * (5 minutes) Vagrant sharing (it's awesomesauce!!!) (bryan) * (15 minutes) Q & A

3 6

Input requested about license codes on MediaWiki.org
by Ricordisamoa 23 Jan '15

23 Jan '15

I would appreciate anyone's participation on this proposal <https://www.mediawiki.org/wiki/Thread:Template_talk:ExtensionLicense/SPDX_n…> I've started to use standard identifiers for licenses. Thanks in advance.

1 1

Office Hours for EventLogging & Dashboarding
by Kevin Leduc 14 Jan '15

14 Jan '15

Please join the Analytics Engineering team for... Office Hours: EventLogging & Dashboarding Hosts: Dan and Nuria Date: January 14 Time: 20:00 UTC - Convert to Local Time <http://www.timeanddate.com/worldclock/fixedtime.html?msg=EventLogging+and+D…> Hangout: https://plus.google.com/hangouts/_/wikimedia.org/a-batcave IRC: #wikimedia-analytics Description: Teams need metrics on how their product or feature is performing, then they need to visualize those metrics. This is accomplished with instrumenting code with EventLogging, mashing data with some queries and setting up a Limn Dashboard. The Analytics Engineering team is open for office hours to answer questions about the process, help solve any issues and listen to feedback on the process. Feel free to drop in the Goolge Hangout linked above or ask questions on the IRC channel during our Office Hours.

2 4

[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

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