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_6th>
For a longer term view, see the new Roadmap project in Phabricator:
<https://phabricator.wikimedia.org/tag/roadmap/>
A quick list of notable items for next week...
== All Week ==
* The convertion of LQT pages on MediaWiki.org to Flow will begin on
Monday and progress throughout the week.
* Deploying the SandboxLink extension to cluster and enable on wikis
where it currently is a gadget will likely happen next week; date TBD.
== Monday ==
* ContentTranslation will be enabled on Vietnamese Wikipedia
** <https://phabricator.wikimedia.org/T91164>
== Tuesday ==
* MediaWiki deploy
** group1 to 1.25wmf24: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.25/wmf24>
== Wednesday ==
* MediaWiki deploy
** group2 to 1.25wmf24 (all Wikipedias)
** group0 to 1.26wmf1 (test/test2/testwikidata/mediawiki)
*** Just calling it out, 1.26 begins this day
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hello.
I'm a developer at reddit, and this morning I was looking into how we
generate thumbnail images from Wikipedia (and I suppose all Mediawiki)
articles, due to a user report that they had an unexpected thumbnail on
their submission[0].
You can read my post there for more details, but essentially since we can't
find an og:image or other similar metadata tag hinting to us what we should
use for a thumbnail, we iterate through all the linked images on the page
and pull out the largest one (you can view the code online if you're
curious[1]). While this works reasonably well as a general heuristic,
Wikipedia articles often have some more structure that could give us a
better image to use.
While writing this, I recalled that the Wikipedia Android app displays
thumbnails in its search results. I think that's pulling from OpenSearch
with the PageImages extension[2]? but I haven't really delved into that
yet. I'm curious how those images get pulled - if it's taking into account
infoboxes or such, or just the first image on the page, or what.
Would it be feasible to include an og:image tag on pages for which we have
a reasonable guess as to the thumbnail? Open Graph[3] is supported by what
seems anecdotally to me to be a wide range of services, so good hints there
would improve thumbnails for links on not just reddit, but Facebook,
Twitter, various chat clients, I think several Wordpress plugins, etc.
Thanks,
- P
[0]:
https://www.reddit.com/r/bugs/comments/317n1v/thumbnail_acquisition_from_wi…
[1]:
https://github.com/reddit/reddit/blob/master/r2/r2/lib/media.py#L485-L542
[2]: https://www.mediawiki.org/wiki/API:Opensearch
[3]: http://ogp.me/
Greetings!
Among other things, Parsoid converts HTML to wikitext. There are two
requirements as far as this serialization / conversion goes:
* Preserving HTML -> HTML semantics (i.e. a list when serialized to
wikitext and parsed back should render as an identical list)
* Enforcing certain wikitext norms (i.e. use <nowiki/> to clarify quote
parsing instead of <nowiki>'</nowiki>; serialize categories on their own
line, etc.)
In a large set of scenarios, there is no conflict between these two
requirements, i.e. Parsoid's serialization to conform to certain
wikitext style norms preserves the HTML -> HTML semantics.
But, there are some scenarios where these requirements are in conflict.
This conflict arises when Parsoid receives HTML that is malformed [1],
or sends HTML that has no representation in wikitext [2], or sends HTML
that will serialize to wikitext that editors will complain about [3]. We
have adopted a somewhat adhoc strategy so far while favouring the HTML
-> HTML preservation strategy.
In some scenarios like [1], it is easier to argue that Parsoid should
break HTML -> HTML semantics by effectively blaming the breakage in HTML
roundripping on the client.
But, it is a little less clear in scenarios like [3]. ==<nowiki/>== is
clearly valid wikitext and can be parsed back to preserve HTML
semantics, there is a good argument to be made to also drop such empty
headers in Parsoid. So, even though WYSIWYG model breaks here, that
could be seen as a less serious bug that outputting ==<nowiki/>==.
That said, we definitely do not want to get into the business of
implementing ad hoc heuristics to work around client bugs (while we have
and could continue implement temporary workarounds till client bugs are
fixed). That is a slippery slope to code complexity.
So, two questions to answer here:
1. Are there a set of wikitext norms that are applicable across wikis
and should be enforced as a syntactic style standard by Parsoid
independent of clients? What are they and can they be documented on a
wiki page by the editor community? Dont' emit "==<nowiki/>==" be one of
those?
2. Independent of (1), should Parsoid implement an optional HTML
normalization pass that it applies on behalf of clients when the right
API parameter is passed in? This might be useful in scenarios where it
is simpler to fix bad HTML than prevent the generation of bad HTML.
In an ideal situation, if we can establish norms for (1), it will
eliminate the need for (2) -- (2) is less desirable and is mostly a
fallback beyond (1).
Thanks,
Subbu.
[1] T94599: https://phabricator.wikimedia.org/T94599
[2] Example: <a data-my-attribute="foo" href="http://google.com">foo</a>
or see T94766: https://phabricator.wikimedia.org/T94766
[3] T94867: https://phabricator.wikimedia.org/T94867
Hi all,
I'm very pleased to announce that as of <s>today</s>yesterday, Moritz
Mühlenhoff will be joining the Ops team in the role of Operations
Security Engineer. We're excited as for the first time we'll have an
engineer on our team able to focus on enhancing the security of our
infrastructure.
Some of you Debian users may recognize his name; in his spare time
he's very active in the Debian Security Team and sends out a large
portion of their security advisory mails. ;)
Moritz lives in Bremen, North Germany (internationally perhaps best
known for being the home of Beck's beer) with his spouse Silvia and
their 16 m/o son Tjark. Besides being a Debian Developer, he also very
much enjoys Rugby Union and plays tighthead prop in his local club
"Union 60 Bremen" in the third divison of Germany. He used to be a
frequent visitor of film festivals such as the San Sebastian festival,
but with the baby around home theatre has become more prevalent. :-)
Moritz is working with us remotely, and can usually be found using his
nick "jmm" on Freenode.
Please join me in welcoming Moritz to the team!
--
Mark Bergsma <mark(a)wikimedia.org>
Lead Operations Architect
Director of Technical Operations
Wikimedia Foundation
Hi,
I'd like to be able to calculate the molar mass of chemical compounds
using a Lua module so that I could use the output in my infoboxes for
chemical compounds and drugs alike. The problem is, I haven't the
foggiest how to set up a module, even one that sounds so simple. I was
hoping that someone may be able to set things up for me, or at least
show me how to do so myself^1 if I gave them the basic idea of what I
was hoping this module would do.
Say we call the module Molar mass calculator (i.e., @ /Module:Molar mass
calculator/ on my local Wiki is where its Lua code is and the template
that invokes it /Template:Molar mass calculator/^2 ). I was thinking of
the Lua module using a pair of vectors one (A⇀\vec{A}) containing the
user-defined variables^3 of all 84 chemical elements found in
appreciable quantities in nature and the other containing the average
atomic mass for all these elements (M⇀\vec{M}). Then doing the Lua
equivalent to a dot product (i.e., A⇀⋅M⇀=∑i=184AiMi\vec{A}\cdot \vec{M}
= \sum_{i=0}^{84} A_i M_i) between these two vectors and using the
result as the module's output which would then//used by the template as
its output.
Footnotes
1. Keeping in mind I am a programming noob, especially when it
comes to Lua, so talk to me like a maths guy that just
understands a little MATLAB, NumPy, SciPy, Python and Wikitext
and no other programming languages as this is fairly accurate.
2. /Template:Molar mass calculator/, presently has this Wikitext
(hence if a change is required please do alert me to it):
{{#invoke:Molar mass calculator}}<noinclude>{{Clr}}
{{documentation}}</noinclude>
3. These variables are those provided to /Template:Molar mass
calculator/ as arguments. For example, if I want to call the
template in a Wiki page it may look like this for Ethanol (C_2
H_6 O)
{{Molar mass calculator
|C = 2
|H = 6
|O = 1
}}
and should provide the output of 46.0694 g/mol.
Thanks for your time,
Brenton
Hi Community Metrics team,
this is your automatic monthly Phabricator statistics mail.
Number of accounts created in (2015-03): 388
Number of active users (any activity) in (2015-03): 838
Number of task authors in (2015-03): 461
Number of users who have closed tasks in (2015-03): 215
Number of tasks created in (2015-03): 3461
Number of tasks closed in (2015-03): 2830
Number of open and stalled tasks in total: 20757
Median age in days of open tasks by priority:
Unbreak now: 48
Needs Triage: 88
High: 113
Normal: 373
Low: 668
Needs Volunteer: 498
TODO: Numbers which refer to closed tasks might not be correct, as described in T1003.
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on iridium at Wed Apr 1 00:00:05 UTC 2015)
Hi there,
I created a Request for comments[1] and a corresponding Phabricator
Task[2] regarding a feature that enables users to watch categories for
page additions and removals.
If you are interested in this topic or somehow involved in
Extension:Echo or watchlist features, feel free to participate in the
discussion.
Cheers,
Kai
[1]: https://www.mediawiki.org/wiki/Requests_for_comment/Watch_Categorylinks
[2]: https://phabricator.wikimedia.org/T94414
--
Kai Nissen
Software-Entwickler
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://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.
Hello,
Happy to inform that we could successfully complete the global
deployment[1] of Extension:BounceHandler and the Wikipiedia's are handling
bounce emails effectively. The current threshold for the number of allowed
bounces is 5, and we could test the unsubscribe action live on
en.wikipedia.org with help of sysops ( I couldnt send more than 2 emails,
thanks to the Anti-spam checks ).
As of now, 'bounce_records' have 37338 entries, mainly from group0 and
group1 wikis ( in ~ 20 days ). We expect an exponential increase in the
same, as the en-wiki has got amazing bounce rates.
This would mean the finish ( deployment ) of my GSoC 2014 project[2] with
Jeff Green and Legoktm. Thanks to everyone who helped in between, it was
real fun!
[1] https://phabricator.wikimedia.org/T92877
[2] mediawiki.org/wiki/VERP
Thanks,
Tony Thomas <http://tttwrites.wordpress.com/>
FOSS@Amrita <http://foss.amrita.ac.in>
*"where there is a wifi, there is a way"*
Hi all,
Just a friendly reminder that 1.25 development is coming to an end and
REL1_25 will be cut next week. If there's anything you really want to get
into 1.25 before the branch and want to avoid a backport now is the time
to do it.
Was planning to do it sometime Tuesday so master is 1.26alpha for the
1.26wmf1 branch on Wednesday.
-Chad