Legoktm | 28 May 03:53 2016
Picon
Gravatar

MediaWiki-Codesniffer 0.7.2 released (bugfix)

Hi,

I just released MediaWiki-Codesniffer 0.7.2, which is a bugfix release
for 0.7.1. There was an issue[1] in the SpacyParenthesisSniff that would
sometimes eat the content inside of the parenthesis or brackets. I ran a
script to check and the only extension that was affected and had bad
code committed was ArticlePlaceholder, which has already been fixed.
Thanks to Thiemo and Nikerabbit for reporting, and PleaseStand for the
patch. Additionally, EBernhardson overhauled how our tests run so we now
have the ability to test sniffs that automatically fix code, which will
hopefully prevent regressions like this in the future!

I submitted autogenerated patches to upgrade all extensions that were
already at 0.7.1 to upgrade to 0.7.2 - they should only touch composer.json.

[1] https://phabricator.wikimedia.org/T134857

-- Legoktm

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ryan Kaldari | 28 May 01:36 2016
Picon

Should we switch the default category collation to uca-default?

There are currently 94 WMF wikis using UCA category collation rather than
the default "uppercase" collation. The Unicode Collation Algorithm (UCA) is
the official standard for how to sort Unicode characters, and generally
follows how a human would typically alphabetize strings. For example,
uppercase collation sorts Aztec, Ärsenik, Zoo, Aardvark as "Aardvark,
Aztec, Zoo, Ärsenik", but uca-default collation sorts them as "Aardvark,
Ärsenik, Aztec, Zoo". UCA collation also (optionally) supports natural
numeric sorting so that 100, 1, 99 sorts as "1, 99, 100" rather than "1,
100, 99". The WMF Community Tech team has recently posted proposals on
English Wikipedia and several Wiktionaries asking if these communities
would support switching to UCA collation. The proposal on English Wikipedia
has received unanimous support so far.[1] We thought that Wiktionaries
would be more skeptical of the change, but so far we have received only
positive responses.[2]

Since it seems that most wikis are receptive to switching to UCA, maybe we
should just make it the default rather than waiting on all the wikis to
request it separately. Of the large Wikipedias, French, Dutch, Polish,
Portuguese, and Russian are already using UCA, and German is in the process
of switching.[3] For non-Latin scripts, my understanding is that UCA will
be a big improvement, especially if we switch them to language-specific
implementations, like uca-ja, uca-zh, uca-ar, etc.

Three questions:
1. Does switching the default collation from "uppercase" to "uca-default"
sound like a good idea?
2. Should this be proposed on meta or is it too technical?
3. Are there any wikis that would need to opt out of this for some reason?
(I know there are issues with Kurdish,[4] but that's the only one I know
about.)
(Continue reading)

Ori Livneh | 28 May 00:27 2016
Picon
Gravatar

Update from the Perf Team

Hello,

Here's what the performance team has been up to.

== Dashboards & instrumentation ==
We spent time instrumenting software and curating displays of performance
data. We have several new dashboards to share with you:

* Global edit rate and save failures (new)
  https://grafana.wikimedia.org/dashboard/db/edit-count

* Performance metrics (revamped)
  https://grafana-admin.wikimedia.org/dashboard/db/performance-metrics

* Page load performance
  https://grafana.wikimedia.org/dashboard/db/navigation-timing

  ...by continent:
https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-continent
  ...by country  :
https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-geolocation
  ...by browser  :
https://grafana.wikimedia.org/dashboard/db/navigation-timing-by-browser

* We found that certain browsers were reporting wildly inaccurate timing
data and skewing our summary performance metrics, and reacted by validating
browser metric data more strictly against Navigation Timing API specs.

== ResourceLoader ==
ResourceLoader is the MediaWiki subsystem responsible for loading CSS,
(Continue reading)

Rachel Farrand | 27 May 22:17 2016
Picon

Wikimania Hackathon Registration Closing!

Hello Wikimedia Developers,

We are quickly reaching capacity at the Esino Lario hackathon and will be
closing registration for the hackathon next week on Tuesday, May 31.

If you have not yet registered but plan on attending, now would be a good
time to do so.

Reminder: You need to register for BOTH the hackathon and the Wikimania
main event if you are planning to attend both. We are not able to post a
public list of everyone who has registered so please email the hackathon
team: me, Nick & Simone (CCed) before Monday if you are unsure of your
registration or have questions.

More information about the event itself will go up on the event page linked
below in the coming weeks and we will email all registered participants
with further information as well.

https://wikimania2016.wikimedia.org/wiki/Hackathon

Thanks! & See you in Italy!
Rachel
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Strainu | 27 May 10:57 2016
Picon

Which Phabricator project for site issues?

Hi,

Is Wikimedia-Site-requests the correct project to log issues with a
specific Wiki? If not, which is it?

Thanks,
  Strainu
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Brad Jorsch (Anomie | 26 May 20:56 2016
Picon

Campaigns extension / ServerSideAccountCreation log - does anyone still use it?

Question 1: Would anyone care if we kill the "loginCTA" campaign, which
tracks when people use the link at the bottom of Special:UserLogin to get
to the account creation page?

Question 2: Would anyone care if we remove the extension entirely from
Wikimedia wikis? Wikiapiary seems to show only one user outside of
Wikimedia.

Background: The extension needs a rewrite for AuthManager, and in
particular the "loginCTA" campaign will be a bit of a pain to keep working.
If someone is making use of the extension that's fine, but if not we may as
well not continue to spend development resources on it.

--

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Deborah Tankersley | 25 May 22:55 2016
Picon

Wikipedia.org article statistics updated

Hello,

Just a quick note: the Discovery Portal team updated the articles by
language statistics on wikipedia.org this morning. I've attached a small
screenshot to this email that displays the new numbers.

Cheers,

Deb
--
Deb Tankersley
Product Manager, Discovery
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Matthew Flaschen | 25 May 19:35 2016
Picon

Collaboration team scrum of scrums update

====Collaboration====
* Blocking
** External Store work on Beta is back in our court. We'll resume soon.
* Blocked
** We've asked for a schema change for new Echo functionality.  Ops has
started looking at this.
* Updates
** Echo MVC refactoring merged
** Some deletion fixes to core and Flow
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Rob Lanphier | 25 May 18:05 2016
Picon
Gravatar

ArchCom-RFC triage meeting later today (22:00 UTC/2pm PDT)

Hi everyone,

We're planning on making today's RFC office hour[1] a triage meeting (at my
request).  The agenda I'm planning to use is to (reasonably) quickly step
through the list of RFCs in the backlog column of the ArchCom-RFC board.  A
wiki copy of this is posted on mediawiki.org[3], which I invite edits to
(albeit with the usual risk of edit conflicts).

The goal of this meeting will be to get through as many of the RFCs, where
I give a gut check for what the priority is, y'all tell me how wrong I am,
and then I set the priority.

For those of you that can't make it, don't sweat it.  Nothing is set in
stone; Phab tickets are easy enough to edit.  Furthermore, I'd like to
experiment with using a Phab Conpherence room for ongoing triage: Phab:Z425
[4].  Conpherence rooms are a bit more persistent than IRC conversations,
are cognitively cheaper to set up and use than mailing lists, and they
integrate nicely with Phab.  If there's a comment about something we do in
the E187 meeting that you wish you had been there to make, and you don't
feel it's appropriate for a wikitech-l posting, the Z425 Conpherence room
is a great place to make your comment.

I'm looking forward to chatting with y'all!

Rob

[1] E187: RFC Meeting: triage meeting (2016-05-25, #wikimedia-office)
https://phabricator.wikimedia.org/E187
[2] #ArchCom-RFC board: https://phabricator.wikimedia.org/tag/archcom-rfc/
[3] Preliminary ordered list of items for triage:
(Continue reading)

John | 25 May 17:41 2016
Picon

HTTPS only

I am trying to double check my code and see if I have any remaining code
using a non-secure connection. Do we have tools for assisting in this?
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Erica Litrenta | 25 May 13:15 2016
Picon

FW: File with an unknown copyright status on MediaWiki.org

On Commons AFAIK
https://commons.wikimedia.org/wiki/Template:No_license_since is used, and
the uploader is warned on their talk page that the file could be deleted
after 7 days if no info is provided.

E.
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Gmane