Re: [Wikitech-l] garbage characters show up when fetching wikimedia api

[Trung Dinh]

Guys, 

Thanks so much for your prompt feedback.
Basically, what I am doing is to keep sending the request based on date &
time until we reach to another day.
Specifically, what I have is something like:

api_url = 'http://en.wikipedia.org/w/api.php'
date='20160504022715'

while (True):
  api_params = 
'action=query=recentchanges=5000=edit=0
ir=newer=json={date}'.format(date=date)
  f = urllib2.Request(api_url, api_params)
  source = urllib2.urlopen(f, None, 300).read()
  source = json.loads(source)
  Increase date.

Given the above code, I am encountering an weird situation. In the query,
if I set rclimit to 500 then it runs normally. However, if I set rclimit
to 5000 like my previous email, I will see the error. I know that for
recent change rclimit should be set to 500. But is there anything
particular about the values of rclimit that could lead to the break in
json ?

On 5/5/16, 11:16 PM, "Wikitech-l on behalf of MZMcBride"

wrote:

>Trung Dinh wrote:
>>Hi all,
>>I have an issue why trying to parse data fetched from wikipedia api.
>>This is the piece of code that I am using:
>>api_url = 
>>'https://urldefense.proofpoint.com/v2/url?u=http-3A__en.wikipedia.org_w_a
>>pi.php=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=K9jJjNfacravQkfypdTZOg=Gl3eq
>>wsc58M_ot8G6G2qehCjARnv3B19Uv5b6hApJz4=AjBJxhe0ZaeTqz3r3wPQOH_kiIjq2_h4
>>UgKIgJUC5XQ= '
>>api_params = 
>>'action=query=recentchanges=5000=edit=0
>>c
>>dir=newer=json=20160504022715'
>>
>>f = urllib2.Request(api_url, api_params)
>>print ('requesting ' + api_url + '?' + api_params)
>>source = urllib2.urlopen(f, None, 300).read()
>>source = json.loads(source)
>>
>>json.loads(source) raised the following exception " Expecting ,
>>delimiter: line 1 column 817105 (char 817104"
>>
>>I tried to use source.encode('utf-8') and some other encodings but they
>>all didn't help.
>>Do we have any workaround for that issue ? Thanks :)
>
>Hi.
>
>Weird, I can't reproduce this error. I had to import the "json" and
>"urllib2" modules, but after doing so, executing the code you provided
>here worked fine for me: .
>
>You probably want to use
>'https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_w_a
>pi.php=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=K9jJjNfacravQkfypdTZOg=Gl3eqw
>sc58M_ot8G6G2qehCjARnv3B19Uv5b6hApJz4=aw9laFsQi8JGilqru0zbRUlrBdcWj52NmF
>tRw6ZW5sI= ' as your
>end-point (HTTPS, not HTTP).
>
>As far as I know, JSON is always encoded as UTF-8, so you shouldn't need
>to encode or decode the data explicitly.
>
>The error you're getting generally means that the JSON was malformed for
>some reason. It seems unlikely that MediaWiki's api.php is outputting
>invalid JSON, but I suppose it's possible.
>
>Since you're coding in Python, you may be interested in a framework such
>as .
>
>MZMcBride
>
>
>
>___
>Wikitech-l mailing list
>Wikitech-l@lists.wikimedia.org
>https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] garbage characters show up when fetching wikimedia api

[Antoine Musso]

Le 05/05/2016 21:56, Trung Dinh a écrit :
> I have an issue why trying to parse data fetched from wikipedia api.
> This is the piece of code that I am using:
> api_url = 
> 'http://en.wikipedia.org/w/api.php'
> api_params = 
> 'action=query=recentchanges=5000=edit=0=newer=json=20160504022715'
> 
> f = urllib2.Request(api_url, api_params)
> print ('requesting ' + api_url + '?' + api_params)
> source = urllib2.urlopen(f, None, 300).read()
> source = json.loads(source)
> 
> json.loads(source) raised the following exception " Expecting , delimiter: 
> line 1 column 817105 (char 817104"
> 
> I tried to use source.encode('utf-8') and some other encodings but they all 
> didn't help.
> Do we have any workaround for that issue ? Thanks :)

The error is due to the response not being valid json.

Can you have your script write the failing content to a file and share
it somewhere? For example via https://phabricator.wikimedia.org/file/upload/

There is a very thin chance that the server/caches actually garbage the
tail of some content.  I have seen some related discussion about it
earlier this week.


-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] garbage characters show up when fetching wikimedia api

[Brad Jorsch (Anomie)]

On Thu, May 5, 2016 at 6:16 PM, MZMcBride  wrote:

> The error you're getting generally means that the JSON was malformed for
> some reason. It seems unlikely that MediaWiki's api.php is outputting
> invalid JSON, but I suppose it's possible.
>

There is https://phabricator.wikimedia.org/T132159 along those lines,
although it's not an API issue.

I note that the reported issue is with list=recentchanges, the output of
which (even at a constant timestamp offset) could easily change with page
deletion or revdel.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] garbage characters show up when fetching wikimedia api

[MZMcBride]

Trung Dinh wrote:
>Hi all,
>I have an issue why trying to parse data fetched from wikipedia api.
>This is the piece of code that I am using:
>api_url = 'http://en.wikipedia.org/w/api.php'
>api_params = 
>'action=query=recentchanges=5000=edit=0
>dir=newer=json=20160504022715'
>
>f = urllib2.Request(api_url, api_params)
>print ('requesting ' + api_url + '?' + api_params)
>source = urllib2.urlopen(f, None, 300).read()
>source = json.loads(source)
>
>json.loads(source) raised the following exception " Expecting ,
>delimiter: line 1 column 817105 (char 817104"
>
>I tried to use source.encode('utf-8') and some other encodings but they
>all didn't help.
>Do we have any workaround for that issue ? Thanks :)

Hi.

Weird, I can't reproduce this error. I had to import the "json" and
"urllib2" modules, but after doing so, executing the code you provided
here worked fine for me: .

You probably want to use 'https://en.wikipedia.org/w/api.php' as your
end-point (HTTPS, not HTTP).

As far as I know, JSON is always encoded as UTF-8, so you shouldn't need
to encode or decode the data explicitly.

The error you're getting generally means that the JSON was malformed for
some reason. It seems unlikely that MediaWiki's api.php is outputting
invalid JSON, but I suppose it's possible.

Since you're coding in Python, you may be interested in a framework such
as .

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] garbage characters show up when fetching wikimedia api

[Trung Dinh]

Hi all,
I have an issue why trying to parse data fetched from wikipedia api.
This is the piece of code that I am using:
api_url = 
'http://en.wikipedia.org/w/api.php'
api_params = 
'action=query=recentchanges=5000=edit=0=newer=json=20160504022715'

f = urllib2.Request(api_url, api_params)
print ('requesting ' + api_url + '?' + api_params)
source = urllib2.urlopen(f, None, 300).read()
source = json.loads(source)

json.loads(source) raised the following exception " Expecting , delimiter: line 
1 column 817105 (char 817104"

I tried to use source.encode('utf-8') and some other encodings but they all 
didn't help.
Do we have any workaround for that issue ? Thanks :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Labs-l] Fall 2015 Tool Labs user survey data published

[Pine W]

Sounds good. Thank you.

Pine

Pine
On May 5, 2016 08:19, "Bryan Davis"  wrote:

> On Wed, May 4, 2016 at 8:35 PM, Pine W  wrote:
> >
> > Hi Bryan,
> >
> > Thanks for the report. With this information in hand, what follow up is
> > planned?
>
> The primary purpose of the study was to set a baseline of qualitative
> ("how are we doing") responses. These will be used to gauge
> increase/decrease in satisfaction in comparison to future surveys.
> Tool Labs staff get regular feedback from people who are either
> extremely happy or extremely unhappy with services, but a broad survey
> like this is helpful to determine the general satisfaction of those
> who are not motivated to provide feedback by a single incident. No
> specific timetable has been set yet, but I expect to see another
> survey run between October and December of this year.
>
> Data from this survey, especially the free form comments, has already
> been shaping the quarterly planning for the Labs techops team and my
> more recent Tool Labs support initiative. I would say that a focus on
> making Tool Labs easier to use, especially by individuals who are not
> experts in the Unix command-line, is a general theme that is being
> pursued as we also seek to replace aging services like Sun Grid Engine
> and increase overall stability of the platform.
>
> One of the things that stood out the most for me personally in the
> feedback was a general need for tutorials and other task focused
> technical documentation. This is an area that I would like to
> encourage the existing Tool Labs developers to help with. There are
> some ideas of things to write in Phabricator [0][1]. Generally we are
> lacking on "big picture" documentation. We have a lot of documentation
> on solving particular problems but even those documents can be
> difficult to find and understand as they are mostly written with an
> assumption of familiarity with the services and terminology used in
> Tool Labs.
>
> [0]: https://phabricator.wikimedia.org/T101659
> [1]: https://phabricator.wikimedia.org/T123425
>
> Bryan
> --
> Bryan Davis  Wikimedia Foundation
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
>
> ___
> Labs-l mailing list
> lab...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/labs-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2016-05-04 Scrum of Scrums meeting notes

[Legoktm]

On 05/05/2016 08:24 AM, Grace Gellerman wrote:
> https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-04
> 
> = 2016-05-04 =
> 
> ==Analytics ==
> *Still trouble with jenkins

Are there any more details about this or a bug filed for it?

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2016-05-04 Scrum of Scrums meeting notes

[Jon Robson]

Yes. Thanks. I think I've done my bit. Let me know if there is
anything else you need from me.

On Thu, May 5, 2016 at 9:58 AM, Željko Filipin  wrote:
> On Thu, May 5, 2016 at 5:52 PM, Jon Robson  wrote:
>
>> Can you clarify what you need help with here? Is it merging
>> patches/updating empty columns on that table/other?
>>
>> Which tests are failing?
>>
>
> Tests fail all the time. See this task for some history:
>
> https://phabricator.wikimedia.org/T94150
>
> Sometimes a job is broken for more than a month. I would like to avoid
> that. I need one or more people to be owners of Selenium tests for each
> repository, so when something is broken, they fix it.
>
> Did I answer your question?
>
> Željko
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] REL1_27 branches up

[Chris Steipp]

On Thu, May 5, 2016 at 8:50 AM, Chad  wrote:

> On Thu, May 5, 2016 at 8:19 AM Gergo Tisza  wrote:
>
> > On Thu, May 5, 2016 at 4:31 PM, Chad  wrote:
> >
> > > Well then it sounds like it won't make the 1.27 release. We've known
> > > this branching was coming for the last 6 months :)
> > >
> >
> > Is there a way to do a backport before the release candidate gets
> > published? The problem with doing major changes after an LTS release is
> > that both the old and the new version has to be maintained for the full
> > support cycle.
> >
> >
> If it can get done in time, sure. I know there's a strong desire to land it
> prior to the release but we can't hold it up forever :)
>
>
There were very minor changes I suggested to the patches that Gergo was
cleaning up earlier this week (like, can we not call the api module
ResetPassword when the special page is PasswordReset). At this point, I'm
fine if it juts gets merged.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2016-05-04 Scrum of Scrums meeting notes

[Željko Filipin]

On Thu, May 5, 2016 at 5:52 PM, Jon Robson  wrote:

> Can you clarify what you need help with here? Is it merging
> patches/updating empty columns on that table/other?
>
> Which tests are failing?
>

Tests fail all the time. See this task for some history:

https://phabricator.wikimedia.org/T94150

Sometimes a job is broken for more than a month. I would like to avoid
that. I need one or more people to be owners of Selenium tests for each
repository, so when something is broken, they fix it.

Did I answer your question?

Željko
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] REL1_27 branches up

[Chad]

On Thu, May 5, 2016 at 8:19 AM Gergo Tisza  wrote:

> On Thu, May 5, 2016 at 4:31 PM, Chad  wrote:
>
> > Well then it sounds like it won't make the 1.27 release. We've known
> > this branching was coming for the last 6 months :)
> >
>
> Is there a way to do a backport before the release candidate gets
> published? The problem with doing major changes after an LTS release is
> that both the old and the new version has to be maintained for the full
> support cycle.
>
>
If it can get done in time, sure. I know there's a strong desire to land it
prior to the release but we can't hold it up forever :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] load.php will now enforce the "no sessions" constraint

[Brad Jorsch (Anomie)]

It has long been the case that the load.php entry point, to support more
aggressive caching, should not depend on details of the current session.
For example, it should not access the session user, and should use its own
'lang' parameter for i18n messages rather than the session user's language.

After a fair bit of work[1] by Gergő Tisza, Timo Tijhof, Bryan Davis, and
myself, we have now flipped the switch to make attempted session access
fail with an exception when serving load.php. This will go out to Wikimedia
wikis with 1.28.0-wmf.1 next week.[2]

We've had this in logging mode for a while and haven't seen any log
messages in production recently, so we anticipate that this change won't
cause any issues for Wikimedia wikis. Third-party wikis may have to update
their extensions.

If there are problems, they'll manifest as missing CSS or JavaScript in the
page, and when examining the load.php output there will be a comment at the
top reporting that a BadMethodCallException was caught. The logged
exception's message will be "Sessions are disabled for this entry point".


 [1]: See https://phabricator.wikimedia.org/T127233 and its subtasks.
 [2]: See https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the
schedule.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2016-05-04 Scrum of Scrums meeting notes

[Jon Robson]

On 5 May 2016 9:24 a.m., "Grace Gellerman"  wrote:
>
> https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-04
>
> = 2016-05-04 =
>
> == Technology ==
>
>
> === Release Engineering ===
>
>
> For all:
>
>
>  * T128190 - Migration of browsertests* Jenkins jobs to selenium* jobs

Hi Zeljko,
Can you clarify what you need help with here? Is it merging
patches/updating empty columns on that table/other?

Which tests are failing?
Jon

>
> ** The migration of browsertests* to selenium* is almost complete,
however,
> Željko needs people to claim their failing browser tests. See the task for
> more information.
>
> *** The task has a table, but it's not clear what you want people to do
> (are you just asking about the rows with missing "contact from
> browsertests.yaml" fields)?
>
>
> For operations:
>
>
> * T126594 - Disable HHVM fcgi server on CI slaves
>
> * Need help from ops to review and merge these two patches (we dont need
> HHVM running as a daemon on CI boxes):
>
> ** https://gerrit.wikimedia.org/r/#/c/269946/
>
> ** https://gerrit.wikimedia.org/r/#/c/269947/
>
>
> * https://phabricator.wikimedia.org/T133911 - Bump quota of Nodepool
> instances (contintcloud tenant)
>
> ** More instances needed. Clarified with Chase last week: pending Andrew.
> No urgency.
>
>
> * Two related tasks, each have patches that are needed to streamline the
> scap3 migration:
>
> ** T133211 - Automate the generation deployment keys (keyholder-managed
ssh
> keys)
>
> *** https://gerrit.wikimedia.org/r/#/c/284418/
>
> ** T132747 - scap::target shouldn't allow users to redefine the user's key
>
> *** https://gerrit.wikimedia.org/r/#/c/285519/
>
>
> === Security ===
>
> * Reviews:
>
> ** json-schema done, AuthManger done (no more comments, a few minor things
> before all patches are +1'ed)
>
> ** Starting on T129584 this week
>
> * Starting work on AuthService next week (heads up to Services, we'll
> probably be scheduling a few meetings with you) (Marko: ack && yay!)
>
> * Ops: ping again on T128819
>
>
> === Services ===
>
> (Marko cannot attend today, sorry)
>
> * RESTBase
>
> ** working on storing all auth checks locally (now we are calling the MW
> API every time)
>
> * EventBus / Change propagation
>
> ** started using it in production for the summary endpoint today
>
> ** more dependency updates to follow soon
>
> * Cassandra move to 2.2.6 soon
>
> ** first up: maps cluster
>
> * use Scap3 -
> https://lists.wikimedia.org/pipermail/wikitech-l/2016-April/085299.html
>
>
> === Technical Operations
>
> * '''Blocking''':
>
> ** none
>
> * '''Blocked''':
>
> ** none
>
> * '''Updates''':
>
> ** May 15 (Chrome SPDY removal deadline). Getting HTTP/2 working fully
> deployed till then
>
> ** started using letsencrypt for various small services
>
>
> == Product ==
>
> === Reading ===
>
> * Most of Reading engineering is at an offsite today, I believe.
>
>
>  Reading Infrastructure 
>
> * AuthManager core patches are just waiting for security +1s. Work is
> ongoing on extensions; CentralAuth, LdapAuthentication, ConfirmEdit could
> use reviews if anyone is interested.
>
>
> === Editing ===
>
>  Collaboration 
>
> * '''Blocking''':
>
> ** External store work.  External Store deployed everywhere on Beta with
no
> complications.  Work on this continues.  We now need to set up a second
> External Store on Beta for Flow, to test the migration.
>
> * '''Blocked''':
>
> ** Work on Flow dumps continuing on the ops side.
> https://phabricator.wikimedia.org/T119511 and
> https://phabricator.wikimedia.org/T89398 .
>
> * '''Updates''':
>
> ** Continuing notification work on:
>
> *** Cross-wiki notifications coming by default on May 12th!
>
> *** Echo email formatter
>
> *** Work continues on the new Echo MVC architecture
>
>
>  Parsing 
>
> * We got our first visual diff test run comparing Tidy with HTML5depurate.
> Results @ http://mw-expt-tests.wmflabs.org/ ... Making notes @
> https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy ... We will use this
> as the basis for figuring out what things might break if we replace Tidy
> today and what needs fixing and where.
>
> * Scott has been working with Ops to get OCG kinks ironed out.
>
>
>  Language 
>
> * '''Blocking''':
>
> ** Apertium->Jessie. Yet to finalize plan and proceed.
>
> * '''Blocked''':
>
> * '''Updates''':
>
> ** cxserver service will be migrated to scap3 deployment soon.
>
> ** Translate (twn, meta,..) now using Apertium MT from cxserver.
>
>
> == Discovery ==
>
> * '''Blocking''': none
>
> * '''Blocked''': none
>
> * Preparing for ElasticSearch 2.0 migration
>
> * Results for A/B test on portal language link location published:
>
https://commons.wikimedia.org/wiki/File:Wikipedia_Portal_Test_of_Language_Detection_and_Primary_Link_Resorting.pdf
>
> * TextCat A/B test launching soon
>
> * Portal A/B test adding descriptions to project links to start this week
>
> * WDQS redeployed, some performance issues
>
> * Graphs have 

Re: [Wikitech-l] Reviving SVG client-side rendering task

[Brion Vibber]

On Thursday, May 5, 2016, Brad Jorsch (Anomie) 
wrote:

> On Thu, May 5, 2016 at 9:49 AM, Brion Vibber  > wrote:
> There's also the font issue: with the current rasterizing, only certain
> free fonts are available and we know what it falls back to. Serve the SVG
> to the client and those free fonts may well be missing (falling back to
> who-knows-what), while other fonts with different metrics that our
> rasterizer ignores might be present on the client.


Yep... It's worth experimenting with injecting fonts into the
"thumbnail" SVG output. That'll increase total download size again, but
common fonts should be shared between files, making them neatly cacheable,
and if there are no relevant characters we have no need to inject them.

I think all the CSS @font stuff works in SVG as it does in HTML, so if we
have known client-side-safe fonts we can reference them as we do in
HTML land... For common cases where text is in the language of the
surrounding site, that means we may have loaded the same font already if
one was needed.


Making SVG safe for fallback fonts can indeed be tricky if the metrics
don't match, though for simple labels it's usually a matter of setting
reasonable bounding boxes and making use of the alignment specifications,
rather than using the tightest possible bounding box and aligning things
manually by x/y.

For extreme cases where exact glyph shapes and metrics matter because the
text is mixed with graphical elements directly, files should probably
use paths instead of text (or at least embed a specific SVG font made of
specific paths). That can be something that good authoring tools can help
with.

-- brion

>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2016-05-04 Scrum of Scrums meeting notes

[Željko Filipin]

On Thu, May 5, 2016 at 5:24 PM, Grace Gellerman 
wrote:

> https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-04
>
> = 2016-05-04 =
>
> == Technology ==
>
>
> === Release Engineering ===
>
>
> For all:
>
>
>  * T128190 - Migration of browsertests* Jenkins jobs to selenium* jobs
>
> ** The migration of browsertests* to selenium* is almost complete, however,
> Željko needs people to claim their failing browser tests. See the task for
> more information.
>
> *** The task has a table, but it's not clear what you want people to do
> (are you just asking about the rows with missing "contact from
> browsertests.yaml" fields)?


Please see "Ownership of Selenium tests" e-mail sent to this list yesterday
for more information.

In short, I need to populate this table:

https://phabricator.wikimedia.org/T134492

Željko
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2016-05-04 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-05-04

= 2016-05-04 =

== Technology ==


=== Release Engineering ===


For all:


 * T128190 - Migration of browsertests* Jenkins jobs to selenium* jobs

** The migration of browsertests* to selenium* is almost complete, however,
Željko needs people to claim their failing browser tests. See the task for
more information.

*** The task has a table, but it's not clear what you want people to do
(are you just asking about the rows with missing "contact from
browsertests.yaml" fields)?


For operations:


* T126594 - Disable HHVM fcgi server on CI slaves

* Need help from ops to review and merge these two patches (we dont need
HHVM running as a daemon on CI boxes):

** https://gerrit.wikimedia.org/r/#/c/269946/

** https://gerrit.wikimedia.org/r/#/c/269947/


* https://phabricator.wikimedia.org/T133911 - Bump quota of Nodepool
instances (contintcloud tenant)

** More instances needed. Clarified with Chase last week: pending Andrew.
No urgency.


* Two related tasks, each have patches that are needed to streamline the
scap3 migration:

** T133211 - Automate the generation deployment keys (keyholder-managed ssh
keys)

*** https://gerrit.wikimedia.org/r/#/c/284418/

** T132747 - scap::target shouldn't allow users to redefine the user's key

*** https://gerrit.wikimedia.org/r/#/c/285519/


=== Security ===

* Reviews:

** json-schema done, AuthManger done (no more comments, a few minor things
before all patches are +1'ed)

** Starting on T129584 this week

* Starting work on AuthService next week (heads up to Services, we'll
probably be scheduling a few meetings with you) (Marko: ack && yay!)

* Ops: ping again on T128819


=== Services ===

(Marko cannot attend today, sorry)

* RESTBase

** working on storing all auth checks locally (now we are calling the MW
API every time)

* EventBus / Change propagation

** started using it in production for the summary endpoint today

** more dependency updates to follow soon

* Cassandra move to 2.2.6 soon

** first up: maps cluster

* use Scap3 -
https://lists.wikimedia.org/pipermail/wikitech-l/2016-April/085299.html


=== Technical Operations

* '''Blocking''':

** none

* '''Blocked''':

** none

* '''Updates''':

** May 15 (Chrome SPDY removal deadline). Getting HTTP/2 working fully
deployed till then

** started using letsencrypt for various small services


== Product ==

=== Reading ===

* Most of Reading engineering is at an offsite today, I believe.


 Reading Infrastructure 

* AuthManager core patches are just waiting for security +1s. Work is
ongoing on extensions; CentralAuth, LdapAuthentication, ConfirmEdit could
use reviews if anyone is interested.


=== Editing ===

 Collaboration 

* '''Blocking''':

** External store work.  External Store deployed everywhere on Beta with no
complications.  Work on this continues.  We now need to set up a second
External Store on Beta for Flow, to test the migration.

* '''Blocked''':

** Work on Flow dumps continuing on the ops side.
https://phabricator.wikimedia.org/T119511 and
https://phabricator.wikimedia.org/T89398 .

* '''Updates''':

** Continuing notification work on:

*** Cross-wiki notifications coming by default on May 12th!

*** Echo email formatter

*** Work continues on the new Echo MVC architecture


 Parsing 

* We got our first visual diff test run comparing Tidy with HTML5depurate.
Results @ http://mw-expt-tests.wmflabs.org/ ... Making notes @
https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy ... We will use this
as the basis for figuring out what things might break if we replace Tidy
today and what needs fixing and where.

* Scott has been working with Ops to get OCG kinks ironed out.


 Language 

* '''Blocking''':

** Apertium->Jessie. Yet to finalize plan and proceed.

* '''Blocked''':

* '''Updates''':

** cxserver service will be migrated to scap3 deployment soon.

** Translate (twn, meta,..) now using Apertium MT from cxserver.


== Discovery ==

* '''Blocking''': none

* '''Blocked''': none

* Preparing for ElasticSearch 2.0 migration

* Results for A/B test on portal language link location published:
https://commons.wikimedia.org/wiki/File:Wikipedia_Portal_Test_of_Language_Detection_and_Primary_Link_Resorting.pdf

* TextCat A/B test launching soon

* Portal A/B test adding descriptions to project links to start this week

* WDQS redeployed, some performance issues

* Graphs have ability to use WDQS directly now

* Team offsite in 2 weeks (17-21)



==Analytics ==

*Scaling of pageview API , more work than anticipated

*Working new domain analytics.wikimedia.org, wikistats 2.0 migration,
meeting with research to map early states of project

*Still trouble with jenkins

*


== Fundraising Tech ==

* coding new PayPal integration

* pulling in lots of CiviCRM upstream changes

* making CentralNotice fail gracefully in odd cache edge cases

* Casey hanging out with reading offsite

* more work towards replacing 

Re: [Wikitech-l] "Troubleshooting Git/Gerrit/git-review" docs: Help welcome.

[Andre Klapper]

On Wed, 2016-05-04 at 23:28 -0500, Andrew Bogott wrote:
> On 5/4/16 8:59 AM, Andre Klapper wrote:  
> > https://www.mediawiki.org/wiki/Gerrit/Troubleshooting
> 
> Although technically correct, some of those instructions encourage users 
> to use 'git pull.'  Git doc writers, please join me in my crusade to 
> stop gerrit users from ever, ever using 'git pull.'

Please be bold and edit. I'm certainly not an advanced Git user; I just
want the learning curve for new contributors to be less steep.

> Thank you for compiling these docs!

Nah. I just moved, restructured + cleaned up content a bit. :)

If anyone feels like joining the Git/Gerrit doc cleanup efforts: 
I have dumped an incomplete "stuff to do" list in
https://phabricator.wikimedia.org/T134256#2260631 for ideas.
For example, I'd love to kill [[mw:Git/Tips]] + [[mw:Git/Rebase]] as we
already have a Tutorial, an FAQ, Advanced usage, Getting started, ...

Thanks!
andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Labs-l] Fall 2015 Tool Labs user survey data published

[Bryan Davis]

On Wed, May 4, 2016 at 8:35 PM, Pine W  wrote:
>
> Hi Bryan,
>
> Thanks for the report. With this information in hand, what follow up is
> planned?

The primary purpose of the study was to set a baseline of qualitative
("how are we doing") responses. These will be used to gauge
increase/decrease in satisfaction in comparison to future surveys.
Tool Labs staff get regular feedback from people who are either
extremely happy or extremely unhappy with services, but a broad survey
like this is helpful to determine the general satisfaction of those
who are not motivated to provide feedback by a single incident. No
specific timetable has been set yet, but I expect to see another
survey run between October and December of this year.

Data from this survey, especially the free form comments, has already
been shaping the quarterly planning for the Labs techops team and my
more recent Tool Labs support initiative. I would say that a focus on
making Tool Labs easier to use, especially by individuals who are not
experts in the Unix command-line, is a general theme that is being
pursued as we also seek to replace aging services like Sun Grid Engine
and increase overall stability of the platform.

One of the things that stood out the most for me personally in the
feedback was a general need for tutorials and other task focused
technical documentation. This is an area that I would like to
encourage the existing Tool Labs developers to help with. There are
some ideas of things to write in Phabricator [0][1]. Generally we are
lacking on "big picture" documentation. We have a lot of documentation
on solving particular problems but even those documents can be
difficult to find and understand as they are mostly written with an
assumption of familiarity with the services and terminology used in
Tool Labs.

[0]: https://phabricator.wikimedia.org/T101659
[1]: https://phabricator.wikimedia.org/T123425

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] REL1_27 branches up

[Gergo Tisza]

On Thu, May 5, 2016 at 4:31 PM, Chad  wrote:

> Well then it sounds like it won't make the 1.27 release. We've known
> this branching was coming for the last 6 months :)
>

Is there a way to do a backport before the release candidate gets
published? The problem with doing major changes after an LTS release is
that both the old and the new version has to be maintained for the full
support cycle.

AuthManager is a complete rewrite of all authentication-related interfaces,
special pages and APIs (the patch to update the release notes [1] gives a
good overview of the scope). Landing it in 1.28 would mean that future
security fixes would have to be completely rewritten for 1.27, instead of
simply cherry-picked; and updates to authentication-related extensions
would have to be written twice, for two completely different interfaces, if
the author wants to keep the LTS-compatible version up to date. The same
goes for bots/tools which need to interact with the account creation API
(and to a lesser extent the login API as well). Given that 1.27 is going to
be supported for 3 years, that would a significant burden.

I understand that lines have to be drawn somewhere and releases would never
get done if everyone was allowed all the time to get just one more change
in, but major reworkings of security-sensitive core components don't happen
often so cutting some slack there is surely less painful than the
alternative.


[1] https://gerrit.wikimedia.org/r/#/c/282202/29/RELEASE-NOTES-1.27
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reviving SVG client-side rendering task

[Brad Jorsch (Anomie)]

On Thu, May 5, 2016 at 9:49 AM, Brion Vibber  wrote:

> Rendering consistency across browser engines is a concern. Supposedly
> modern browsers are more consistent than librsvg but we haven't done a
> compatibility survey to confirm this or identify problematic constructs.
> This is probably worth doing.
>

There's also the font issue: with the current rasterizing, only certain
free fonts are available and we know what it falls back to. Serve the SVG
to the client and those free fonts may well be missing (falling back to
who-knows-what), while other fonts with different metrics that our
rasterizer ignores might be present on the client.


> And we'll almost certainly want to strip comments and white space to save
> bandwidth on page views, while retaining them all in the source file for
> download and reediting.
>

There's other stuff that could be stripped, too. For example, Inkscape's
default "Inkscape SVG" format saves a lot of extra data under its own
"inkscape" and "sodipodi" namespaces and some style rules with a
'-inkscape-' vendor prefix that we could probably kill.

Inkscape also likes to put 'id' attributes on absolutely everything (e.g.
rect3342, tspan8263), which we could strip if we can somehow determine
they're not used somewhere else (including 

[Wikitech-l] Analytics Kafka Upgrade next week

[Andrew Otto]

Hiya,

We’ll be upgrading the Analytics Kafka cluster from 0.8.2 to 0.9.0.1 next
week.  This is scheduled to start at Wednesday May 11th at 13:00 UTC (9:00
EST, 6:00 PST).

If all goes well*, this should be a rolling upgrade with no downtime.

Just a heads up, thanks!
-Andrew & Luca


*everybody knock on wood now
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] REL1_27 branches up

[Chad]

On Thu, May 5, 2016 at 6:44 AM Brad Jorsch (Anomie) 
wrote:

> On Wed, May 4, 2016 at 9:52 PM, Chad  wrote:
>
> > Minor reminder: please don't start landing large breaking changes on
> > master now that we've swapped...it makes porting patches between
> > branches way more difficult than they need to be :)
> >
>
> We were trying to get AuthManager's core parts merged before the branch cut
> for exactly this reason, but it's still in security review...
>
>
Well then it sounds like it won't make the 1.27 release. We've known
this branching was coming for the last 6 months :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "Troubleshooting Git/Gerrit/git-review" docs: Help welcome.

[Chad]

On Wed, May 4, 2016 at 9:29 PM Andrew Bogott  wrote:

> On 5/4/16 8:59 AM, Andre Klapper wrote:
> > Hej,
> >
> > I went ahead & centralized the 5 git/Gerrit/git-review troubleshooting
> > sections that I've found so far on random mediawiki.org pages into one
> > single page (and eliminated duplicates with different solutions):
> >
> > https://www.mediawiki.org/wiki/Gerrit/Troubleshooting
> >
> >
> Knee-jerk ahead:
>
> Although technically correct, some of those instructions encourage users
> to use 'git pull.'  Git doc writers, please join me in my crusade to
> stop gerrit users from ever, ever using 'git pull.' There's no end to
> the heartbreak that can result from pulling. Pulling merges, and merging
> is gerrit's job.
>
> https://wikitech.wikimedia.org/wiki/Help:Git_rebase
>
>
`git pull -r` is my favorite :)

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Reviving SVG client-side rendering task

[Brion Vibber]

For the last decade we've supported uploading SVG vector images to
MediaWiki, but we serve them as rasterized PNGs to browsers. Recently,
display resolutions are going up and up, but so is concern about
low-bandwidth mobile users.

This means we'd like sharper icons and diagrams on high-density phone
displays, but are leery of adding extra srcset entries with 3x or 4x
size PNGs which could become very large. (In fact currently MobileFrontend
strips even the 1.5x and 2x renderings we have now, making diagrams very
blurry on many mobile devices. See https://phabricator.wikimedia.org/T133496 -
fix in works.)


Here's the base bug for SVG client side rendering:
https://phabricator.wikimedia.org/T5593
I've turned it into an "epic" story tracking task and hung some blocking
tasks off it; see those for more details.

TL;DR stop reading here. ;)


One of the basic problems in the past was reliably showing them natively in
an , with the same behavior as before, without using JavaScript hacks
or breaking the hamlet caching layer. This is neatly resolved for current
browsers by using the "srcset" attribute -- the same one we use to specify
higher-resolution rasterizations. If instead of PNGs at 1.5x and 2x
density, we specify an SVG at 1x, the SVG will be loaded instead of the
default PNG.

Since all srcset-supporting browsers allow SVG in  this should "just
work", and will be more compatible than using the experimental 
element or the classic  which deals with events differently. Older
browsers will still see the PNG, and we can tweak the jquery.hidpi srcset
polyfill to test for SVG support to avoid breaking on some older browsers.

This should let us start testing client-side SVG via a beta feature (with
parser cache split on the user pref) at which point we can gather more
real-world feedback on performance and compatibility issues.


Rendering consistency across browser engines is a concern. Supposedly
modern browsers are more consistent than librsvg but we haven't done a
compatibility survey to confirm this or identify problematic constructs.
This is probably worth doing.


Performance is a big question. While clean simple SVGs are often nice and
small and efficient, it's also easy to make a HUGEly detailed SVG that is
much larger than the rasterized PNGs. Or a fairly simple small file may
still render slowly due to use of filters.

So we probably want to provide good tools for our editors and image authors
to help optimize their files. Show the renderings and the bandwidth balance
versus rasterization; maybe provide in-wiki implementation of svgo or other
lossy optimizer tools. Warn about things that are large or render slowly.
Maybe provide a switch to run particular files through rasterization always.

And we'll almost certainly want to strip comments and white space to save
bandwidth on page views, while retaining them all in the source file for
download and reediting.


Feature parity also needs more work. Localized text in SVGs is supported
with our server side rendering but this won't be reliable in the client;
which means we'll want to perform a server side transformation that creates
per-language "thumbnail" SVGs. Fonts for internationalized text are a big
deal, and may require similar transformations if we want to serve them...
Which may mean additional complications and bandwidth usage.


And then there are long term goals of taking more advantage of SVGs dynamic
nature -- making things animated or interactive. That's a much bigger
question and has implementation and security issues!

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] REL1_27 branches up

[Brad Jorsch (Anomie)]

On Wed, May 4, 2016 at 9:52 PM, Chad  wrote:

> Minor reminder: please don't start landing large breaking changes on
> master now that we've swapped...it makes porting patches between
> branches way more difficult than they need to be :)
>

We were trying to get AuthManager's core parts merged before the branch cut
for exactly this reason, but it's still in security review...


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wikimedia-l] Invitation to upcoming office hours with interim ED

[Gregory Varnum]

Hi Risker,

You are correct, and I apologize for that confusion. When the message was 
originally drafted, there were PDT based times, and the date change was 
accidentally missed when UTC was added.

The pages for the session have been updated to reflect the dates more 
accurately:
Thursday, 12 May 2016 - 00:00-01:00 UTC | Wednesday, 11 May 2016 - 17:00-18:00 
PDT

https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_Director/May_2016_office_hours
 


Thank you for pointing that out. :)

-greg

PS. I personally continue to dislike time zones. ;)


---
Gregory Varnum
Communications Strategist (Contractor)
Wikimedia Foundation 
gvar...@wikimedia.org 


> On May 4, 2016, at 10:01 PM, Risker  wrote:
> 
> Just noting that 1700-1800 PDT on Wednesday May 11 is -0100 UTC on
> Thursday May 12. Based on the link given, this seems to be when the meeting
> will be held. Please verify.
> 
> Risker/Anne
> 
> On 4 May 2016 at 21:28, Pine W  wrote:
> 
>> Forwarding.
>> 
>> Pine
>> -- Forwarded message --
>> From: "Katherine Maher" 
>> Date: May 4, 2016 17:47
>> Subject: [Wikimedia-l] Invitation to upcoming office hours with interim ED
>> To: , , <
>> wikimediaannounc...@lists.wikimedia.org>
>> Cc:
>> 
>> Hi everyone,
>> 
>> **Summary: I am delighted to invite you to join me for two upcoming office
>> hours, where I’ll answer community questions and share updates on the
>> Foundation’s work.**
>> 
>> It’s been a busy few weeks around the Wikimedia Foundation offices. We
>> shared our 2016-2017 annual plan, finished our quarterly reviews, and
>> attended Wikimedia Conference 2016 in Berlin with the Wikimedia affiliates.
>> [1]
>> 
>> In Berlin, I had the chance to do one of my favorite things: sit with
>> Wikimedians, listen, debate, and plan for the future. Of course, Berlin is
>> just one gathering, and there are thousands of other perspectives out
>> there. I want to hear more of these perspectives, and so I’m looking
>> forward to hosting two office hours over the coming weeks.
>> 
>> We plan to hold a traditional office hours on IRC, and will also experiment
>> with a video Q We hope these different formats will make it easier for
>> more people to participate using their preferred communications channels.
>> We’ve chosen two different time zones, with the goal of reaching as many
>> people as possible. They are as follows:
>> 
>> *Video session*
>> *This session will be recorded, and the video will be posted on
>> Commons/Meta. Due to video conferencing limitations, we encourage advance
>> questions.*
>> Wednesday, 11 May 2016
>> 00:00-1:00 UTC | 17:00-18:00 PDT [2]
>> 
>> *IRC session*
>> *This session follows the May monthly metrics meeting.[4] Like other office
>> hours, it will be held in #Wikimedia-office on Freenode.*
>> Thursday, 26 May 2016
>> 19:00-20:00 UTC | 12:00-13:00 PDT [3]
>> 
>> We’re also collecting questions in advance for those who can’t make either
>> of those sessions. We’ve created a page on Meta where you can leave
>> questions or comments, check the details on the location of each session:
>> 
>> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_Director/May_2016_office_hours
>> 
>> Please share this invitation with others you think may be interested!
>> 
>> I look forward to speaking soon,
>> Katherine
>> 
>> Translation notice - This message is available for translation on
>> Meta-Wiki:
>> 
>> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_Director/May_2016_office_hours/Announcement
>> 
>> [1] https://meta.wikimedia.org/wiki/Wikimedia_Conference_2016
>> [2] Time converter link:
>> 
>> http://www.timeanddate.com/worldclock/fixedtime.html?hour=0=00=0=12=05=2016
>> [3] Time converter link:
>> 
>> http://www.timeanddate.com/worldclock/fixedtime.html?hour=19=00=0=26=05=2016
>> [4] https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings
>> 
>> 
>> --
>> Katherine Maher
>> 
>> Wikimedia Foundation
>> 149 New Montgomery Street
>> San Francisco, CA 94105
>> 
>> +1 (415) 839-6885 ext. 6635
>> +1 (415) 712 4873
>> kma...@wikimedia.org
>> ___
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> New messages to: wikimedi...@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> 
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> 

[Wikitech-l] ArchCom-RFC status update: 2016-05-04

[Rob Lanphier]

Hi everyone,

I've included the ArchCom-RFC status update in this mail below, which now
has a dedicated wiki page:


Assuming we build the habit, this should be updated weekly.

Rob


Recent RFC office hours

-   2016-05-04: Phab:E169
-   T130528: RFC: PSR-6 Cache interface in Mediawiki core
-   Declined. A lot of the discussion was about these three
questions:
1.  what problem was this RFC trying to solve?
2.  if BagOStuff is an obstacle, then which is true?
-   a) need a better caching abstraction than BagOStuff?
or
-   b) does BagOStuff just need incremental improvement
-   c) should BagOStuff be deprecated, and not replaced
with anything?

3.  if we decide to rethink our caching model, do we need
tagged caching?

Upcoming RFC office hours

-   2016-05-11: Phab:E66/34(E171)
-   T113034: RFC: Overhaul Interwiki map, unify with Sites and
WikiMap

-   The ArchCom-RfCs board has a "Ready for RFC meeting" column which
should contain an ordered queue of RFCs planned for IRC office hour

Entering Final Comment Period

-   Phab:T120164 - this is a last call for a process RFC about last
calls. See RobLa's email to wikitech-l on 2016-05-04 about this.

RFC inbox

-   ArchCom RFC board:
-   empty on 2016-05-04

Shepherd status

-   Brion
-   (?)
-   Daniel
-   Software Quality working group?
-   Working on Multi Content Rev Spec with Brion
-   Gabriel
-   T39902 RFC: Implement rendering of redlinks as post-processor
(Gabriel): Solutions for highlighting links to non-existing
pages in Parsoid HTML. Plan in place / agreed between Parsing
and Services. Implementation in change propagation service
ready, preparing for deploy possibly next week.
-   T122942 RFC: Support language variants in the REST API
(Gabriel): Waiting for progress on more general question of
language selection granularity / strategy & T114662.
-   Roan
-   I need to start the second part of T108655, but the recent
comments have me confused. I'll need to talk to Timo and figure
out what the subject of part two should be.
-   RobLa
-   Created mw:RFCstatus
-   still need to schedule an RFC triage meeting outside of
ArchCom-RFC time
-   Tim
-   No update
-   Timo
-   No update

No activity in the last two weeks

-   T123753 Establish retrospective reports for Security and Performance
incidents (RobLa)
-   T122825 Service ownership and minimum maintenance requirements
(Gabriel)
-   T124504 Transition WikiDev '16 working areas into working groups
(RobLa)
-   T66214 Use content hash based image / thumb URLs & define an
official thumb API (Brion)
-   T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap
(Daniel)
-   T128351 RFC: Notifications in core (Brion)
-   T122825 Service ownership and minimum maintenance requirements
(Gabriel)
-   T54807: Identify and remove legacy preferences from MediaWiki core
(no shepherd)
-   T88596 Improving extension management (Daniel)
-   T11 RFC: Introduce notion of DOM scopes in wikitext (Tim)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l