Hi everyone,
I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/)
and I need to extra the content from it and convert it into LaTeX
syntax for printed documentation. I have googled for a suitable OSS
solution but nothing was apparent.
I would prefer a script written in Python, but any recommendations
would be very welcome.
Do you know of anything suitable?
Kind Regards,
Hugo Vincent,
Bluewater Systems.
Folks who are interested in downloading tarballs of media for their
particular project can now do so from:
http://ftpmirror.your.org/pub/wikimedia/imagedumps/tarballs/
In this directory you will see two subdirectories, "fulls" and "incrs".
The way this works is that once a month near the beginning of the month
we will produce a series of tarballs for each project of media uploaded
locally and media stored on commons. During the month, at least once
but hopefully twice, we will produce tarballs containing the files
uploaded locally or included from commons since the "full" tarball
date.
No tarballs are being produced for commons itself, given that it's 14T
and there would be no separate locally uploaded/remotely uploaded lists.
Instead please use rsync to get those files directly from:
rsync://ftpmirror.your.org/wikimedia-images/wikipedia/commons/
Also, please bear in mind that for author and license information you
should download the corresponding pages-meta-current.xml.bz2 file from
http://dumps.wikimedia.org/ or your local mirror, and check the
corresponding File: description pages for your project or commons.
And now it's time as usual for the Big Fat Disclaimer:
We're still running these manually, it's possible that we won't make the
planned schedule for a given run or runs, network connectivity might be
unstable, etc. etc. Its also possible we will restructure the fulls so
that they take a lot less space and rely on three series of tarballs for
some projects.
Thanks once again to your.org for donating the time, space and bandwidth
to make this possible.
Ariel
I have now had multiple issues in Translate extension that are related
to database replication. After doing write to the master, some
maintenance tasks kick in and use slave to read the (now stale) data.
I've heard that there is some automatic handling for this, so that
editors for example see the latest version of Article after saving it.
But apparently there is no such thing, or at least it doesn't kick in
automatically.
What should I do? I don't fancy adding parameters to many methods to
define whether to use master or slave for data retrieval. Is there
method that waits for the used slave to catch up with the state after
last write?
-Niklas
--
Niklas Laxström
Hi all,
June 6, 2012 is IPv6 Day ( http://www.worldipv6day.org/ ). The goal of
this global event is to move more ISPs, equipment manufacturers and
web services to permanent adoption of IPv6.
We're planning to do limited production testing of IPv6 during the
Berlin Hackathon 2012 (June 2-3). Provided that the number of issues
we encounter are manageable, we may fully enable IPv6 on IPv6 day, and
keep it enabled.
MediaWiki has been used with IPv6 by third party wikis for some time.
Wikimedia uses a set of additional features (GlobalBlocking,
CheckUser, etc.) which weren't fully IPv6-ready until recently. In
addition, we're working to ensure that all of Wikimedia's various
services (mailing lists, blogs, etc.) are IPv6-ready.
== What's the user impact going to be? ==
At least in the June 2-3, 2012 time window, you may see a small number
of edits from IPv6 addresses, which are in the form
"2001:0db8:85a3:0000:0000:8a2e:0370:7334". See [[w:IPv6 address]].
These addresses should behave as any other IP adress would: You can
leave messages on their talk pages; you can track their contributions;
you can block them. CIDR notation is supported for rangeblocks.
An important note about blocking: A single user may have access to a
much larger number of addresses than in the IPv4 model. This means
that range blocks (e.g. address with "/64") have to be applied in more
cases to prevent abuse by more sophisticated users.
In the mid term, user scripts and tools that use simple regular
expressions to match IPv4 addresses will need to be adapted for IPv6
support to behave correctly. We suspect that IPv6 usage is going to be
very low initially, meaning that abuse should be manageable, and we
will assist in the monitoring of the situation.
User:Jasper Deng is maintaining a comprehensive analysis of the long
term implications of the IPv6 migration here:
https://en.wikipedia.org/wiki/User:Jasper_Deng/IPv6
We've set up a test wiki where you can see IPv6 IP addresses. This
works by assigning you a fake IPv6 address the moment you visit the
wiki, and allows you to see the behavior of various tools with the new
address format:
http://ipv6test.wmflabs.org/wiki/index.php/Main_Page
The best way to report issues is to register them in Bugzilla and to
ensure that they are marked as blockers for the IPv6 tracking bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=35540
We'll post updates to wikitech-l and elsewhere as appropriate.
All best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Hi
I was wondering what the policy is for the right to merge into core, i.e. for
being able to give +2 and "publish and submit" on gerrit. There sooms to be
total confusion about the policy for that.
To me this seems more or less equivalent to commit access to svn, no?
Anyway. I pretty much need it for the core/Wikidata branch, and wouldn't mind to
have it for core/master, too.
-- daniel
As someone who writes css, I am particularly frightened by IE7. And I can
imagine there are a lot of frontend developers and staff out there who
spend significant time on fixing things for this niche audience, when they
could be working on more constructive things. I came across this service
today which has started to levy a a surcharge on IE7 users [1] and it got
me thinking.
6% of wikimedia project page views are from IE6/7 - because of the
following:
- IE6 ships default with XP
- Legal users with SP2+ can upgrade to IE8
- If you have 90s era hardware, no SP for you. Can only be solved by buying
some new hardware (or switching to linux)
- IT admins who dont know much about IT and have kept the workforce hostage
through their ignorance. Can be solved if the workforce and boss demands it.
- People new to computers and are not really sure how to use the mouse.
They need to be told IE7 is bad and how to upgrade
- Those without an internet connection. Can be solved by not using the
internet.
- IE7/mspaint hipsters. No solution.
As one of the most visited places on the internet, it is probably in the
best interests of the planet that we decide its no longer worthwhile to
support this fallen angel. Maybe it time to start showing a notice to IE7
users that their days are numbered and wikipedia may no longer work as
expected unless they move forward in their lives. It has to happen some
day, so why not now and save the internet a lot of pain and suffering?
[1] http://www.kogan.com/au/blog/new-internet-explorer-7-tax/
--
j.mp/ArunGanesh
Yes, Microsoft was great when they made IE 6, but when IE 7 came out, Microsoft killed
the Internet star. I mean, HTML 5? What? I read a book that said after HTML 4.01, it would
be XHTML 1.0, XHTML 1.1 ... not HTML 5!
Tyler Z
On Thu, 14 Jun 2012 20:45:20 +0200, Andre Engels wrote:
>On Thu, Jun 14, 2012 at 1:46 PM, Chad <innocentkiller(a)gmail.com> wrote:
>
>>Absolutely not. We have debated the "show notice to broken browsers"
>>thing multiple times--and the answer is always "it's annoying as hell
>>when sites do it and it's not our place to do so."
>>
>>The stance on "supporting crappy old browsers" has largely over time
>>turned into--continue supporting all browsers with at least 1% of our
>>readers (roughly,I don't believe that number's ever been set in stone).
>>Once they are less than 1%, continue supporting unless it's a burden
>>to do so and/or makes support for newer browsers impossible. And lastly,
>>never purposefully break a browser if you can help it.
>
>Just to give some data: Looking at May, this 1% limit would mean
>supporting the following browser versions (May 2012 data):
>
>* Chrome 18.0 and 19.0
>* MSIE 6.0, 7.0, 8.0 and 9.0
>* Firefox 3.6, 11.0 and 12.0
>* Safari 534.55 (desktop), 6533.18 and 7534.48 (iOS)
>* Opera 11.62 and 11.64
>* Safari 533.1 (Android browser)
>
>Furthermore, the following have no version at or over 1%, but do get
>there or at least near when all versions are combined:
>* Opera Mini
>* WikipediaMobile (our own mobile app)
>* BlackBerry browser
>* Apple PubSub (rss reader)
>
>--
>André Engels, andreengels(a)gmail.com
>
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l(a)lists.wikimedia.org
>https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Daniel Friesen wrote:
> IT departments need to start maintaining their computers and employees
> need to start demanding that the computers they work with are kept to
> modern standards.
> People keep bringing up legacy apps as a reason that IT departments
> cannot give employees a properly maintained browser environment.
> But as I explained that's BS because there are other options than simply
> upgrading IE. The argument that it would be confusing to employees is
> also BS because that's easily covered by making everyone use
> Firefox/Chrome/etc... for all web browsing and placing shortcuts on the
> desktop that open up pages in IE to make it look like the internal
> systems are apps rather than websites. Well, that or using chrome frame.
> So basically this boils it down to pointing it out that the arguments
> saying that a proper browsing environment "can't" be provided is BS. And
> this is not something they can't do, it's just something they won't.
> Which is a case we should not be catering to and enabling.
Right... well, again, just like the OP, you're focusing on how you feel the
world should be while completely ignoring reality. It's not a matter of
catering to obstinate IT folks. It's a matter of being pragmatic about the
current landscape and its limitations.
MZMcBride