Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_April_21st>
A quick list of notable items...
== Tuesday ==
* MediaWiki deploy
** group1 to 1.24wmf1: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf1>
* Flow:
** Archive and enable Flow on the Nearby Pages Beta Feature talk page
** <https://www.mediawiki.org/wiki/Talk:Beta_Features/Nearby_Pages>
** <https://www.mediawiki.org/wiki/Flow>
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf1 (all Wikipedias)
** group0 to 1.24wmf2 (test/test2/testwikidata/mediawiki)
* Media Viewer:
** Third limited pilot release: Enable by default on a few small
pilot sites (batch 2: Czech, Estonian, Finnish, Hebrew, Polish,
Romanian, Slovak, Thai, Vietnamese)
** <https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan#Timeline>
As always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi all,
Typography Refresh was one of the first batch of Beta Features launched
last November. It's also now the first Beta Feature that was removed and
then deployed in core. You'll probably have noticed the many threads about
it on Wikitech in the past. ;-)
While this might not have been a particularly large technical change (it's
mostly just some tweaks to the Vector Less styles in core) we wanted to
publicly share notes from the team about it. The purpose of a retrospective
is to focus on concrete actions we can take to ensure good process.
Hopefully we have learned some lessons that could help other beta features
testing/release go smoothly.
Notes are up at
https://www.mediawiki.org/wiki/Typography_refresh/Retrospective if you're
interested. Since these reflect the feelings of the team working on it, I'd
like to ask that you first add questions and comments on the Talk page,
rather than directly to the document.
Thanks!
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
Hi!
I was surprised to see that Twitter is now the preferred method of
contacting the Wikimedia Foundation, and that it is much more effective
than long disputes and discussions on mailing lists, Bugzilla and wiki
pages.
Indeed, it is so effective that it leads to the WMF clearly preferring
un-free fonts over their free equivalents; something that, I believe,
participants of this very mailing lists agreed /not/ to do.
FYI: <https://en.wikipedia.org/w/index.php?diff=602800100>.
Tomasz
Hello,
I just wanted to make everyone aware of a discussion going on at the English
Wikipedia. They are discussing changing the Main Page, not visibly, but just
changing the page from a table based layout to one that is a little bit more
modern. The discussion can be found here:
https://en.wikipedia.org/wiki/Talk:Main_Page#Proposal_to_implement_new_fram…
_for_main_page
One of the things that came up during the discussion was testing the framework
with a wide variety of browsers. A lot of the opposition to it that I could see
came from the lack of testing. I feel like I remember us discussing here
previously a framework for testing stuff across many browsers. If we have
something of the like here, I think that it could be well deployed to help them
out. No reason for them to re-invent the wheel or do all of the testing
manually.
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
Hi all,
we have just deployed a new URL format for MediaViewer [0], I am submitting
it here for comments and for the benefit of people who have to do something
similar in other contexts.
MediaViewer stores the name of the image in the hash part of the URL so one
can share links to a page with a specific image open in the lightbox. (We
considered using the History API [1] to change the path or the query part,
but that degrades poorly.) I have looked at three options:
1. Just put the file name as-is (with spaces replaced by underscores) in
the URL fragment part.
Pro: readable file names in URLs, easy to generate.
Con: technically not a valid URI. [2] (It would be a valid IRI,
probably, but browser support for that is not so great, so non-ASCII bytes
might get encoded in unexpected ways.) Creates nasty usability and security
issues (injection vulnerabilities, RTL characters, characters which break
autolinking). Would make it very hard to introduce more complex URL formats
later, as file names can contain pretty much any character.
2. Use percent encoding (with underscores for spaces).
Pro: this is the standard way of encoding fragments. [2][3] Always
results in a valid URI. Readable file names in Firefox. Easy to generate
on-wiki (e.g. with {{urlencode}})
Con: Non-Latin filenames look horrible in any browser that's not Firefox.
3. Use MediaWiki anchor encoding (like percent encoding, but use a dot
instead of a percent sign).
This would have the advantage that links can be generated in
wikitext very conveniently, using the [[#...]] syntax. Unfortunately the
way MediaWiki does percent encoding is intrinsically broken (the dot itself
does not get encoded, but it does get decoded when followed by suitable
characters, so file names cannot get roundtripped safely), so this is not
an option.
We went with option 2, so URLs look like this:
https://www.mediawiki.org/wiki/Lightbox_demo#mediaviewer/File:Swallow_flyin…https://www.mediawiki.org/wiki/Lightbox_demo#mediaviewer/File:%E0%AE%85%E0%…
One issue that we ran into is that window.location.hash behaves weirdly
with percent-encoded hashes in Firefox [4], but that's easy to avoid once
you know about it. Other than that, it seems to work reliably.
[0] https://www.mediawiki.org/wiki/Multimedia/Media_Viewer
[1] http://diveintohtml5.info/history.html
[2] http://tools.ietf.org/html/rfc3986#section-3.5
[3] https://tools.ietf.org/html/rfc3987#section-3.1
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=483304
Since we're considering
https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_int…
and asking for discussion on
https://www.mediawiki.org/wiki/Requests_for_comment/Content_API , I put
some time into understanding what a Service-Oriented Architecture and
Representational State Transfer mean in general, and what they'd mean
for MediaWiki. Here's what I think we're talking about. Please correct
me where I'm wrong!
So, just to clarify, this is NOT a discussion of overhauling the
outward-facing MediaWiki web API -- that's taking place in
https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap .
Instead, this is about refactoring how MediaWiki works *internally*, for
everything from page editing to export to watchlists to permissions to
stats. (And we've already sort of started doing this; see how Parsoid
gives you parsing-as-a-service, for instance.)
The way we do stuff now: within your code, you write your core or
extension code so that it interacts with various objects, subclasses
this and event-handles that and hooks into the other thing. And there
are several files and classes and globals that you kind of have to
interact with to do many different things, like index.php and $wgTitle
and $mediawiki .
A service-oriented architecture would change this; instead, code authors
would be able to read and write data via services. You sort of see this
now, in how there's a Notifications service and a Parsoid service that
new core or extensions code can push to or read from. In an SOA, we'd
extend that to include LOTS of functionality - basically any retrieval
or modification of data that a new feature might request or activate
that, in a more monolithic architecture, would require direct database
access or other permanent data store.
REST (Representational State Transfer) is a model for how those services
would work. Any given chunk of data is a resource. We have well-defined
verbs in HTTP for the service's client to use when either asking for a
representation of that resource (GET) or suggesting a new representation
so as to get the service to change the state of the resource (often POST).
So the future might look like: the heart of MediaWiki core is PHP code
that talks to the database and provides well-defined interfaces for
other components to talk to by saying, e.g., GET /pages/123 , PUT
/pages/123 . There are a bunch of examples in
https://www.mediawiki.org/wiki/Requests_for_comment/Storage_service_and_con…
although I don't quite understand the question marks in the URIs.
Is this about right?
---------------------
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
More. Ideas? I emailed mobile-l already, in case you're not on the list.
---------- Forwarded message ----------
From: Adam Baso <abaso(a)wikimedia.org>
Date: Wed, Apr 16, 2014 at 2:20 PM
Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org>
Great idea!
Anyone on the list know if there's a way to make the debug log facilities
do the YYYYMMDD timestamp instead of the longer one?
If not, I suppose we could work to update the core MediaWiki code. [1]
-Adam
1. For those with PHP skills or equivalent, I'm referring to
https://git.wikimedia.org/blob/mediawiki%2Fcore.git/a26687e81532def3faba646….
Scroll to the bottom of the function definition to see the datetimestamp
approach.
On Wed, Apr 16, 2014 at 12:47 PM, Andrew Gray <andrew.gray(a)dunelm.org.uk>wrote:
> Hi Adam,
>
> One thought: you don't really need the date/time data at any detailed
> resolution, do you? If what you're wanting it for is to track major
> changes ("last month it all switched to this IP") and to purge old
> data ("delete anything older than 10 March"), you could simply log day
> rather than datetime.
>
> enwiki / 127.0.0.1 / 123.45 / 2014-04-16:1245.45
>
> enwiki / 127.0.0.1 / 123.45 / 2014-04-16
>
> - the latter gives you the data you need while making it a lot harder
> to do any kind of close user-identification.
>
> Andrew.
> On 16 Apr 2014 19:17, "Adam Baso" <abaso(a)wikimedia.org> wrote:
>
> > Inline.
> >
> > Thanks for starting this thread.
> > >
> > > Sorry if I've overlooked this, but who/what will have access to this
> > data?
> > > Only members of the mobile team? Local project CheckUsers? Wikimedia
> > > Foundation-approved researchers? Wikimedia shell users? AbuseFilter
> > > filters?
> > >
> >
> > It's a good question. The thought is to put it in the customary
> wfDebugLog
> > location (with, for example, filename "mccmnc.log") on fluorine.
> >
> > It just occurred to me that the wiki name (e.g., "enwiki"), but not the
> > full URL, gets logged additionally as part of the wfDebugLog call; to
> make
> > the implicit explicit, wfDebugLog adds a datetime stamp as well, and
> that's
> > useful for purging old records. I'll forward this email to mobile-l and
> > wikitech-l to underscore this.
> >
> >
> > > And this may be a silly question, but is there a reasonable means of
> > > approximating how identifying these two data points alone are? That is,
> > > Using a mobile country code and exit IP address, is it possible to
> > > identify a particular editor or reader? Or perhaps rephrased, is this
> > data
> > > considered anonymized?
> > >
> >
> > Not a silly question. My approximation is these tuples (datetime, now
> that
> > it hit me - XYwiki, exit IP, and MCC-MNC) alone, although not perfectly
> > anonymized, are low identifying (that is, indirect inferences on the data
> > in isolation are unlikely, but technically possible, through examination
> of
> > short tail outliers in a cluster analysis where such readers/editors
> exist
> > in the short tail outliers sets), in contrast to regular web access logs
> > (where direct inferences are easy).
> >
> > Thanks. I'll forward this along now.
> >
> > -Adam
> > _______________________________________________
> > Wikimedia-l mailing list
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
