We had shelved my patch, patch 64629 <https://gerrit.wikimedia.org/r/64629>,
in hopes that an earlier patch, patch
35233 <https://bugzilla.wikimedia.org/show_bug.cgi?id=35233>), would
resolve the issue naturally as Google re-indexed. But it appears Google has
re-indexed and yet the .zero.wikipedia.org URLs are still present in
Google's index, instead of the <language>.wikipedia.org URLs.
I have thus resubmitted patch 64629 <https://gerrit.wikimedia.org/r/64629> for
re-review. We will need to further discuss whether it is appropriate to
have Google completely remove .zero.wikipedia.org links from their cache,
or if perhaps we need to open a support thread with Google about canonical
On Tue, May 28, 2013 at 1:13 PM, Kul Wadhwa <kwadhwa(a)wikimedia.org> wrote:
> Adam Baso (copied on this email) is working on it and a fix is ready.
> He'll do some testing to make sure it's resolved.
> On Tue, May 28, 2013 at 10:22 AM, Tomasz Finc <tfinc(a)wikimedia.org> wrote:
>> Looping Dan Foy in who's managing the Zero backlog.
>> On Mon, May 27, 2013 at 8:01 AM, MZMcBride <z(a)mzmcbride.com> wrote:
>> > K. Peachey wrote:
>> >>Can you please file this in bugzilla <https://bugzilla.wikimedia.org>?
>> > https://bugzilla.wikimedia.org/show_bug.cgi?id=48856
>> > MZMcBride
>> > _______________________________________________
>> > Wikimedia-l mailing list
>> > Wikimedia-l(a)lists.wikimedia.org
>> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>> Wikimedia-l mailing list
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> Kul Wadhwa
> Head of Mobile
> Wikimedia Foundation
I recently helped shepherd a new skin into Mediawiki;
I would like to think it is perfect in every way, but one area it
hasn't had any love is making sure it works well on mobile devices.
To the best of my knowledge it shouldn't do anything particularly
heinous, but I don't have any such devices to test it on. If anybody
has a few minutes and could have a play, and see if anything could
be improved, please do and let me know on list.
A live example of it is at
which should have full editing etc rights enabled. It's a dummy
wiki, so add whatever you like.
Thanks in advance!
Re-trying to send this as the message was rejected several times and I
have no idea why.
---------- Forwarded message ----------
From: Guillaume Paumier <gpaumier(a)wikimedia.org>
Date: Thu, Mar 28, 2013 at 5:53 PM
Subject: Please read: Proposal to consolidate Mobile projects documentation
A few weeks ago, Tomasz asked me to investigate the possibility of
consolidating the Mobile projects documentation, currently split
between meta and mediawiki.org.
I've done some inventorizing and planning:
What I'd like to ask you guys now is the following:
* Do you see any reason not to move forward with this plan?
* Could you take a look at the content on meta and delete what's
obsolete (and doesn't need archiving)?
* When would be the best time to do the actual move? I expect the move
to take about a day, and I'd like to choose a time that minimizes
Let me know if you have any concerns or questions :)
Recently, more bugs with dynamic sections resurfaced. Here is the
* We mangle HTML in beta and alpha, removing all sections but 0 and
relying on JS to provide the rest.
* The former approach does not work with non-JS user-agents and when
JS is disabled or simply didn't get loaded (we're on mobile after
* Pure-HTML fallback with links to separate sections doesn't sound
promising due to performance concerns.
** Because there's no sane way to purge the cached sections.
** And because we'll have to either spend more CPU time on every
mobile section view than on whole desktop view OR cache aggressively
and compete with parser cache, thus reducing overall cluster
This is very broken and because there's no chance that it will be
moved into core in its present state it fails the beta inclusion
criteria (for final testing of features that will soon be exposed to
Therefore, I propose to do away with it and if we still want dynamic
section views in the foreseeable future, use plan B that I proposed
* Leave HTML as it is.
* Load subsequent pages dynamically.
** While the first page load may seem much heavier than just section 0
+ section headings, due to the amount of JS we serve, the
percentage of bandwidth saved by stripping sections is reasonably
low except for a few really huge pages.
** Subsequent page views work as before.
** All fallbacks work magically.
** Implementation is straightforward and requires much less work to
make it production-quality.
** No performance bells ringing.
Max Semenik ([[User:MaxSem]])
We were just talking about various ideas for Google Glass (a
conversation which was sparked when I mentioned the thread here) and
someone (eclectiqus) mentioned "Wikipedia 4d".
This would work off of geo-coded photos, of course. Say you're standing
where the Berlin Wall was and, of course, it isn't there any more.
A Glass app (operating with a sizable number of geo-coded photos on
Commons) could re-create the view you would have had 25 years ago at
Now, how to add geo-coding to old photos...
Imagination does not breed insanity. Exactly what does breed insanity
is reason. Poets do not go mad; but chess-players do.
-- G.K. Chesterson