James Forrester, Florian, and I met Wednesday, 22-July-2015 to discuss the
Editing roadmap, with the backdrop of editing modes available in mobile web
and apps but both the mobile web and apps teams now being in the Reading
* FY 2015-2016: active Editing development for apps not planned
* General plan is to replace the current mobile web editing experiences
with new (replacement) VE and wikitext editor maintained by the VE team for
* Q1: VE mobile prototyping (doesn't require Reading involvement)
* Q2: Editing for mobile web replacement *coding* starting, but rollout on
mobile web would begin in some future quarter _after_ Q2
* Feature submission practices for volunteers submitting editing related
stuff for the mobile web for the time being (feature submissions
discouraged for now as it will end up being replaced; mainline VisualEditor
/ next gen wikitext editing in collaboration with VE team would probably
make more sense) -
** Create task in reading-web Phabricator board and indicate the details of
what you were thinking to work on and roughly when. Add James Forrester and
Joaquin Hernandez to card.
** Reach out to James_F (Senior Product Manager, VisualEditor) and joakino
(Reading Web engineering product owner and tech lead) on #wikimedia-mobile
on Freenode to discuss the idea and to determine who would need to code
review and test
* Code review for bugfixes for the existing mobile editing code should be
done by Reading Web, and code review plus testing should be done by Editing
as well. Ping joakino and James_F on IRC to figure out who to add to
* As the Editing team gets into the practice of submitting patches for
MobileFrontend to swap out the editor, as usual, tasks should be filed well
ahead of time in the reading-web Phabricator board so there's a heads up
about potential code review. Also, Editing and Reading should be tracking
Q2 and subsequent quarter planning together to ensure dependencies are
clearly defined and agreed upon.
I also spoke to Roan from Collaboration after the Scrum of Scrums the same
day. Roan indicated that there isn't an emphasis on rolling out Flow to
mobile Wikipedias en masse for FY 2015-2016. And generally, when Flow does
become slated for rollout on the mobile Wikipedias and sister projects in a
broader sense it shouldn't require work - or anything substantial, anyway -
from the Reading team.
Hi guys !
I'm working on a website, which find your position using geolocation,
and then show the wikipedia's pages around you on an OSM map. For the
moment it works.
The goal here is to create a full solution dedicated to tourism. For
example a tourist is dropped in a city he doesn't know, and he can have
informations on what's around thanks to Wikipedia and wikidata. But I'd
like to add WikiVoyage informations too.
I know it's possible with Wikidata API to enter a position (longitude
and latitude), a range, and have all Wikipedia pages around. Is it
possible to do the same with WikiVoyage pages ?
Thanks a lot ! :)
There's a ticket for removing mobile.wikipedia.org and wap.wikipedia.org
domains/subdomains, which are legacy domain names superceded by
m.wikipedia.org and its subdomains.
The rationale for the removal of these legacy domain names is to help
support HSTS preloading in browsers with the existing TLS SAN cert.
After review of the ticket, can anyone think of a compelling reason to keep
those old domain names?
I'm going to open a separate thread on mobile-l about this given this is
more mobile-targeted, yet some people only operate on one of wikitech-l or
I have upgraded Zuul this morning which has a slight regression. To be
considered for merging, Zuul require the change to have a Verified +2.
In most case that is not a problem since the tests ran and voted V+2
already. But there is a few other cases where Verified is 0 or -1.
The workaround is thus to manually vote Verified +2 in addition to
Code-Review +2. You might have to remove the prior CR+2 to have the
change properly recognized.
The task is:
Will give it a shot tomorrow.
Antoine "hashar" Musso
According to our docs/internal checks, our min php version is 5.3.3.
However as of 6e283d394f31, MediaWiki doesn't work with php 5.3.3 (You
aren't allowed to implement an interface using an abstract method, on
that version of PHP so you get "Fatal error: Can't inherit abstract
function IDatabase::getType() (previously declared abstract in
DatabaseBase) in git/includes/db/Database.php on line 32").
Is it time we up'd our version requirements (And does anyone know if
that would affect lots of third parties?) Or should that change be