Hey all,
WMDE's TCB team is currently working on an improved edit conflict page.
Improving the edit conflict page was wish #1 in the German-speaking
communities' wishlist 2015. After discussions on-wiki and during Wikimania
2016 the team came up with a proposal and a prototype.
It would be so great if you could spread the word in your projects and ask
people if they could have a look on the prototype and comment on the
proposed solution!
Please see
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Edit_Conflicts#Protot…
for more informations.
Thanks a lot!
Best,
Birgit
--
Birgit Müller
Community Communications Manager
Software Development and Engineering
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
A late forward, but this is especially important for gadget authors.
-------- Forwarded Message --------
Subject: [Wikitech-l] Gadget usage of rollback, purge, and markpatrolled
Date: Wed, 29 Jun 2016 13:42:12 -0700
From: Aaron Schulz <aschulz4587(a)gmail.com>
Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
To: wikitech-l(a)lists.wikimedia.org,
mediawiki-api-announce(a)lists.wikimedia.org
TL;DR: Gadgets should use HTTP POST for purge/rollback/markpatrolled
actions.
-------
Some gadgets still use HTTP GET for page purge requests.
In order to better facilitate multi-datacenter traffic routing [1] and to
better comply with web standards [2],
these types of requests should use POST instead. GET is considered, by
specification, to be a "safe method".
Since purge requests perform database writes and potentially significant
rendering updates, they should use a
state-changing HTTP method. Also, achieving of our multi-datacenter goal as
planned involves leveraging safe
HTTP methods to route request to either the closest or the primary
datacenter for optimal performance.
Most of such requests to MediaWiki already require POST, but "purge" is one
of the exceptions. There is no
compelling reason for this to be exceptional, however. Exposing a URL
parameter that does database writes,
reparsing, and cache updates simply by following a link (especial with no
CSRF token) encourages bad practice
(having links that bypass cache) and the risk of performance problems if
such a link becomes popular.
Rollback requests should also use HTTP POST given that it results in a page
edit. The database operations are
far more complex than purge, so in a multi-datacenter system, such requests
(if using HTTP GET) could have much worse performance depending on the
client's location (even if very close to a datacenter). Ideally, reversion
tools would use the
API for rollback, instead of index.php.
The markpatrolled action, like rollback, also involves a GET request with a
token parameter. The core JavaScript
MediaWiki provides already uses the API with POST, but users without
javascript (and some Gadgets) are still using
HTTP GET. The Gadgets should be converted to POST.
Purge, rollback, and markpatrolled support both POST and GET right now.
Gadgets still using GET for these actions
should be converted to use POST instead.
There is a task at T135170 [3] for MediaWiki to require POST for purge
requests.
Also see T88044 [4] for the same requirement for rollback requests.
[1] https://phabricator.wikimedia.org/T92357
[2] https://tools.ietf.org/html/rfc7231#section-4.2.1
[3] https://phabricator.wikimedia.org/T135170
[4] https://phabricator.wikimedia.org/T88044
--
-Aaron
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Forwarding...
---------- Forwarded message ----------
From: Trey Jones <tjones(a)wikimedia.org>
Date: Thu, Aug 4, 2016 at 1:25 PM
Subject: [discovery] Stripping Question Marks From Wiki Searches is Now
Live!
To: A public mailing list about Wikimedia Search and Discovery projects <
discovery(a)lists.wikimedia.org>
*Stripping Question Marks From Wiki Searches*
*Do you ask questions on Wikipedia? Would you like better results?*
*Summary:* Because the large majority of question marks are used to ask
questions by users unfamiliar with bash-style wildcards
<https://en.wikipedia.org/wiki/Glob_(programming)>, the default behavior
for CirrusSearch will now be to ignore question marks (replacing them with
a space). Escaping them with a backslash (\?) will preserve their wildcard
meaning. Regular expressions in *insource:* will not be affected and should
not be escaped. This option can be modified on a per-wiki basis if needed
(see $wgCirrusSearchStripQuestionMarks
<https://github.com/wikimedia/mediawiki-extensions-CirrusSearch/blob/master/…>
).
When people ask *how old is tom cruise?* on Wikipedia they almost certainly
don’t expect the question mark in *cruise?* to match an additional letter.
They aren’t looking for the words *cruised, cruiser, * or *cruises—*but
that’s what they get, and it keeps them from finding the information they
are really after.
Search on Wikipedia (and other Wikimedia projects) includes a lot of
features that most users don’t know about. Most require special keywords,
and some even require specialized knowledge, such as familiarity with
regular expressions. It’s pretty difficult to invoke these special features
by accident.
But search also supports two particular bash-style wildcards without any
special syntax: *** will match any number of characters, and *?* will match
exactly one. Asterisks do come up from time to time, but people use
question marks all the time—because they like to ask questions!
A recent review of query-string features
<https://commons.wikimedia.org/wiki/File:From_Zero_to_Hero_-_Anticipating_Ze…>
called
out quotes and question marks as the two largest-impact predictors of
unsuccessful queries on Wikipedia. In a follow-up survey of queries with
question marks
<https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Dropping_Final_Quest…>
in
six of the top ten Wikipedias (by search volume), most question marks are
being used to ask questions (the other four of the top 10 were not
reviewed). In all ten of the top ten, stripping final question marks
dramatically decreased the number of ?-final queries that got either no
results, or very few results (i.e., less than 3). The improvement was
around 10-45% for ?-final queries, depending on the wiki. The overall
impact is much more modest (less than 0.5%) because queries with question
marks are not terribly common.
As a result of this analysis, we’ve implemented a change to search which
will by default replace question marks with spaces (to preserve the word
boundaries they intend in queries like *how?why?*). This setting can be
changed on a per-wiki basis, and other options include (i) only stripping
question marks at a clear word boundary (such as before a space), (ii) only
stripping question marks at the end of the query, and (iii) leaving the
question marks alone.
For the rarer users who do use question marks as a one-letter wildcard,
when question mark stripping is enabled, question marks can be escaped with
a backslash (e.g., *wiki\?edia*) to preserve their original wildcard
meaning. Power searchers who use *insource:* won’t need to do anything
special; queries with*insource:* will not be modified.
Here's a screenshot
<https://commons.wikimedia.org/wiki/File:Old-are_viruses_living%3F.png> of
the former question mark behavior, where it is treated as a wildcard.
Note that “living?” only matches the name “Livings”, leading to two very
unsatisfactory results.
Here's a screenshot
<https://commons.wikimedia.org/wiki/File:New-are_viruses_living%3F.png> of
the new question mark behavior, where it is ignored. Now the question
and part of the answer can be seen in the snippet for the very first
result, and all of the top three results seem relevant.
(Sorry I can't embed the screenshots—the mailing list won't allow messages
over 40K.)
Trey Jones
Software Engineer, Discovery
Wikimedia Foundation
_______________________________________________
discovery mailing list
discovery(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/discovery
Dear Wiki Tech Ambassadors,
The Collaboration team[1] is working on various products: Notifications[2],
Flow[3] and the new Edit Review improvements project[4]. We have a lot of
news concerning these products that may interest people, but that are not
fitting Tech News inclusion criteria.[5] We want people to be aware of
that's new about our products and I'm questioning various people about the
best option we should consider to have.
As tech ambassadors, you have an interesting experience. That's why I'm
collecting your feedback.
*Is a newsletter format relevant?* By newsletter, I mean a message
distributed on wiki, like Tech News or the visual editor newsletter[6]. Do
you have ideas of a different formats? We may consider to try other things.
*What would be the best message design?* Is short sentences like in Tech
News good? Or would you prefer to have longer messages with more details?
(Longer messages may be more complicated to translate.)
*How often would you like to receive news?* Tech News has a weekly
distribution, VE's newsletter a quarterly one. As one of the main writers
of that news publication, I would prefer to have a monthly distribution,
but your feedback may be different. Note that we now have a(n experimental)
page with most important changes with products we maintain.[7]
Feel free to answer me privately, or by commenting the dedicated
Phabricator task.[8] I'm gathering all answers until next Friday (August
5th).
Thanks *a lot*!
Benoît
[1] https://www.mediawiki.org/wiki/Collaboration
[2] https://www.mediawiki.org/wiki/Notifications
[3] https://www.mediawiki.org/wiki/Flow
[4] https://www.mediawiki.org/wiki/Edit_Review_Improvements
[5] https://meta.wikimedia.org/wiki/Tech/News/For_contributors
[6] https://meta.wikimedia.org/wiki/VisualEditor/Newsletter/Archive
[7] https://www.mediawiki.org/wiki/Collaboration/Deployment_planning
[8] https://phabricator.wikimedia.org/T123538#2505381
--
Benoît Evellin (Trizek)
Community Liaison
Wikimedia Foundation
