In case you haven't seen it, there are some interesting ideas in the
new skin developed by the Blender community for its wiki:
http://wiki.blender.org/index.php/Meta:Skins/Naiad
It was clearly designed especially to support structured documentation:
http://wiki.blender.org/index.php/Doc:2.5/Manual
Among the more interesting ideas employed here are automatic changes
to the layout to make the best use of the available screen resolution.
Cheers,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hey guys,
I just wanna say a _big_ thank you to all the people that were
involved in the design and maintaince of the upload system on Commons!
Over 140k of pictures in a month on top of the regular traffic is
something.
And if we got around to this, can you tell us when were the most
pictures uploaded per minute/hour/day? Do you guys have such
statistics?
Thanks A LOT,
Strainu
Hello to both the wikitech and pywikipedia lists -- please keep both
informed when replying. Thanks.
A few days ago, we - the pywikipedia developers - received alarming
reports of interwiki bots removing content from pages. This does not
seem to happen often, and we have not been able to reproduce the
conditions in which this happens.
However, the common denominator is the fact it seems to be happening
only on the wikipedia's that run MediaWiki 1.18 wikis. As such, I
think this topic might be relevant for wikitech-l, too. In addition,
there is no-one in the pywikipedia team with a clear idea of why this
is happening. As such, we would appreciate any ideas.
1. What happens?
Essentially, the interwiki bot does its job, retrieves the graph and
determines the correct interwiki links. It should then add it to the
page, but instead, /only/ the interwiki links are stored. For example:
http://nl.wikipedia.org/w/index.php?title=Blankenbach&diff=next&oldid=10676…http://eo.wikipedia.org/w/index.php?title=Anton%C3%ADn_Kl%C3%A1%C5%A1tersk%…http://simple.wikipedia.org/w/index.php?title=Mettau%2C_Switzerland&action=…
2. Why does this happen?
This is unclear. On the one hand, interwiki.py is somewhat black
magic: none of the current developers intimately knows its workings.
On the other hand, the bug is not reproducible: running it on the
exact same page with the exact same page text does not result in a
cleared page. It could very well be something like broken network
error handling - but mainly, we have no idea. Did anything change in
Special:Export (which is still used in interwiki.py) or the API which
might cause something like this? I couldn't find anything in the
release notes.
3. Reasons for relating it to MW 1.18
To find out on which wikis this problem happens, I used a
quick-and-dirty heuristic:
select rc_comment, rc_cur_time, rc_user, rc_namespace, rc_title,
rc_old_len, rc_new_len from recentchanges left join user_groups on
ug_user=rc_user where rc_new_len < rc_old_len * 0.1 and ug_group =
'bot' and rc_namespace=0 limit 10 /* SLOW OK */;
This is a slow query (~30s for nlwiki_p on the toolserver), but it
gives some interesting results:
nlwiki: 9 rows, all broken interwiki bots
eowiki: 25 rows, all interwiki bots
simplewiki: 3 rows, of which 2 are interwiki bots
dewiki: 0 rows
using rc_old_len * 0.3: 14 rows, all double redirect fixes
frwiki: 9 rows, but *none* from interwiki bots (all edits are by the
same antivandalism bot)
itwiki: 0 rows
ptwiki: 0 rows
All ideas and hints are very welcome. Hopefully we will be able to
solve this before tuesday...
Best regards,
Merlijn van Deen
Awesome work Christian. Where can we find your code to test out?
If you don't have a place then I'll carve one out in our depots.
On Sep 24, 2011 5:57 AM, "Christian Pühringer" <christian(a)puehringer.net>
wrote:
> Hi Emanuel,
>
> Makes sense that images are not compressed in zim file again, thanks for
the
> clarification.
> In particular for windows mobile this increases the probability that with
> reducing the cluster size
> a sufficient performance is achieved (i.p. if there was a better way to
display
> images than in android, but I haven't looked into this).
> For android I still expect that it it will be better to use a native
library.
>
> Christian
> Am 24.09.2011 14:30, schrieb Emmanuel Engelhart:
>> On 24/09/2011 14:24, Christian Pühringer wrote:
>>> The JAVA liblzma performance is pretty bad: To increase efficiency of
>>> compression in the zim-format articles (and also all
>>> other data like images) are stored in clusters. Cluster size is
apparently about
>>> 1 MB. This implies that loading an article
>>> which is stored at the end of a cluster involves decompressing the
complete
>>> cluster.
>> Images should not be compressed in ZIM files for the obvious reasons
>> they mainly are already compressed. This is the case for all ZIM files I
>> made. As far as I know this is also the case for Mediawiki:Collection
>> build ZIM files.
>>
>> Emmanuel
>>
>
> _______________________________________________
> dev-l mailing list
> dev-l(a)openzim.org
> https://intern.openzim.org/mailman/listinfo/dev-l