Hi,
For javascript unit testing of Mediawiki extensions, qunit can be
used and it is documented at
https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing#QUnit
We also documented(thanks to Krinkle) some guidelines on writing qunit
test cases at https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing/QUnit_guideli…
In the last sprint of i18n team, we have added qunit test cases for
WebFonts extension and as far as I know no other extension use qunit
for unit testing. If you are planning to write js test cases for your
extension please make use of these documentation and help us to
improve it.
Thanks
Santhosh Thottingal
Please find the report on the latest[1] i18n triage below. The rough
notes are on etherpad:
http://etherpad.wikimedia.org/BugTriage-i18n-2012-01.
Thanks go to the participants liangent, Nemo_bis, srikanthlogic,
OrenBo, ^demon, aharoni, Nikerabbit, santhosh and hexmode.
We covered three main topics: WebFonts, Narayam and Translate.
WebFonts
--------------
Support WebFonts for Chinese -- This topic does not yet have a
bugzilla entry. Because of the complexity, it was agreed that Liangent
and Santhosh would discuss firther. Availability of fonts for Chinese
and their potential large size is an issue. This will require some
more discussion to understand the issue more clearly and to think
about solutions -- there are more than 47.000 characters involved.
Liangent suggested Font Subsetting -- creating downloadable fonts
tailored for a pageon the fly -- but there are multiple issues with
that.
Narayam input methods
--------------------------------
https://bugzilla.wikimedia.org/31904 -- Bamini keyboard map needs fix:
We are looking for a community member to validate the mapping.
srikanthlogic volunteered to track somebody down.
https://bugzilla.wikimedia.org/32029 -- Some vowel combination in
Sinhala Wijesekara need to be corrected: We are looking for a
community member to validate the mapping.
https://bugzilla.wikimedia.org/33243 -- Narayam IME on fails to
replace English characters on mobile: This report contains at least
two separate issues. For tracking purposes, that's not great; one
should be split off. Because of the multitude of mobile and tablet
devices, each with their own resolution, screen dimension and aspect
ratio, something like "Narayam on mobile" will probably not be a one
size fits all solution, like it is implemented on desktop browsers.
Siebrand will open a discussion with the mobile team on what we think
we can do with input methods on mobile devices.
https://bugzilla.wikimedia.org/33300 -- Unwanted activation which
disables user's ability to type: It's unclear how to proceed with
this. We are thinking about something visual in the proximity of the
text area or input field. This needs to be discussed with UI/UX
people. Siebrand will follow up, and UI/UX designers have been CC-ed
on the issue, but have not yet added their thoughts.
https://bugzilla.wikimedia.org/33480 -- Add Telugu Transliteration
input method to Narayam: A Telugu community member/developers is
needed to port the existing input method gadget to Narayam. Hexmode
will chase down a tewiki user/dev.
Script to automate transliteration help maps -- This topic does not
yet have a bugzilla entry. srikanthlogic suggested this for
transliteration tables liike
http://www.mediawiki.org/wiki/Help:Extension:Narayam/Tamil/Transliteration.
Opinions differ on if this would contribute anything valuable, as
each transliteration schema is different, and these tables may always
need to be created manually. Siebrand to schedule a session to discuss
this further.
Translate
------------
https://bugzilla.wikimedia.org/31632 -- When re-marking translatable
page for translation, old version of the pages might be shown: It
looks like this behaviour is no longer observed. The issue was closed.
https://bugzilla.wikimedia.org/31695 -- Support Google Translate V2
API: Google has deprecated and limited use of the Translate V1 API.
We're looking for a volunteer to update the interface, but one has not
been found yet.
https://bugzilla.wikimedia.org/32983 -- Page protection leads to issue
in translatable pages: It looks like Translate may be missing a hook
or it might be using the wrong hook. We're planning on asking Roan for
help.
https://bugzilla.wikimedia.org/33647 -- Translate popups with
insufficient height: This appears to be an intermittent, but annoying
issue. During the triage no additional understanding has arisen.
Anyone with information that may reliably reproduce this issue is
requested to please add steps and details in bugzilla.
Cheers! In February, there will be another Localisation and
internationalisation bug triage.
[1] http://lists.wikimedia.org/pipermail/mediawiki-i18n/2012-January/000383.html
--
Siebrand Mazeland
Product Manager Localisation
Wikimedia Foundation
M: +31 6 50 69 1239
Skype: siebrand
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
I've found a bit of an issue with our external image embedding
whitelisting functionality.
This isn't exactly a hole in the code itself, but in the fact that in
practice it seams just about everyone uses the whitelist incorrectly and
ends up opening up holes in their wiki allowing the whitelist to be
bypassed.
I'll start with MW.org for an example:
https://www.mediawiki.org/wiki/MediaWiki:External_image_whitelist
This image whitelist is fine, it's properly anchored with an explicit
protocol and an initial ^, and it's not using excessive wildcards, there's
nothing wrong with it.
However when I do a Google search and try to find some of the top wikis
using the image whitelist functionality I see this:
http://rbose.org/wiki/MediaWiki:External_image_whitelisthttp://mbmodwiki.ollclan.eu/MediaWiki:External_image_whitelisthttp://wiki.vnations.net/index.php/MediaWiki:External_image_whitelisthttp://stelio.net/geeki/MediaWiki:External_image_whitelisthttp://community.wikia.com/wiki/MediaWiki:External_image_whitelist
Basically EVERYONE except the smart people running Wikimedia sites use the
image whitelist incorrectly. There are rules using .* in some but more
importantly NO ONE anchors their whitelist rules (they don't even bother
including the protocol in some cases so we can't even use an implicit
anchor to the regexps).
This means that the whitelists can be trivially bypassed:
http://community.wikia.com/wiki/User:Dantman/Whitelist_hole
In this example Wikia has a `wikia\.com` regexp line in their image
whitelist.
By using something like this the image whitelist is bypassed:
http://imgs.xkcd.com/comics/security_holes.png?wikia.com&image.png
The "?wikia.com" inside of the query triggers the whitelisting allowing
the image to be embedded, and the trailing &image.png makes sure that the
url still matches the internal image url embed regexp.
By adding a query like this (it doesn't even necessarily need to be a
query, I haven't tested but the fragment might be usable, and even if not
it's liable that you could use the path portion of the url if you had a
server setup to serve images for certain weird urls) you can embed
basically any url you want into the wiki since the query portion of the
url is ignored by webservers serving images.
And to be clear I don't believe that patterns like
`http://upload\.wikimedia\.org/` and `^http://(.*?\.)?wordpress\.com/`
aren't safe. I believe that the special characters in the later parts of
the url won't affect it and you can still get it to work. And ^ anchoring
won't work when using .* style wildcards because you can craft a url such
as
http://my.malicious-website.com/path/to/my/evil/image.png?.wordpress.com&im…
which would match that latter regexp.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Deadline: March 31st. Special shout-out to those of you doing data
analytics or visualization -- please take a look and consider submitting
a talk.
-Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
CALL FOR PAPERS - Wikipedia Academy 2012: Research and Free Knowledge.
June 29 - July 1, 2012 | Berlin, Germany
Conference Website: http://wikipedia-academy.de/2012/wiki/Main_Page
Submit your papers here:
https://www.easychair.org/conferences/?conf=wpac2012
The “Wikipedia Academy 2012: Research and Free Knowledge” provides a
platform for the research community and the Wikipedia community to
connect, present, discuss and advance research on Wikipedia in
particular and on free knowledge in general.
The Wikipedia Academy 2012 is organized by Wikimedia Deutschland e.V.
in collaboration with the Alexander von Humboldt Institute for
Internet and Society and Freie Universität Berlin. The conference will
take place in Berlin, June 29 to July 1, 2012. The event will be open
to all interested parties and features a variety of session formats,
ranging from panel discussions and tracks with traditional paper
presentations to break-out sessions, lightning talks, poster
presentations and a science fair. We particularly invite young
doctoral and postdoctoral researcher to participate and to submit
extended abstracts.
For research paper and poster sessions, we encourage the submission of
extended abstracts addressing issues in the overall nexus of Wikipedia
and free knowledge.
== Dates ==
* Submission of extended abstracts: March 31, 2012
* Notification of acceptance: May 01, 2012
* Submission of full papers: June 1, 2012
* Event: June 29 - July 1, 2012
== Topics of interest ==
Submissions are invited for the following categories, further details
will be available soon on the conference website:
http://wikipedia-academy.de/2012/wiki/Submission_process
=== Wikipedia Analytics ===
* Wikis and Wikipedia as a research tool
* Analyzing Wikipedia as a source of "Big Data"
* Assessing and measuring the quality of Wikipedia articles
=== Wikipedia Global ===
* Relations and Differences between national Wikipedias
* Differences between and critique of free/open knowledge ideologies
* Regional studies of Wikipedia and free knowledge with global lessons
=== Sharing Cultures and Practices ===
* Sharing culture(s) in Wikipedia and other projects of commons-based
peer production
* Incentives, innovation and community dynamics in open collaborative
peer production
* Wiki theory and wiki practices
=== Research on Users of and Contributors to Wikipedia ===
* Diversity among users of and contributors to Wikipedia (e.g. Gendergap)
* Influencing participation by adapting user interfaces in open
collaborative settings
* Using information visualization as information instrument to users
and contributors
=== Economic and Regulatory Aspects of Free Knowledge ===
* Economic, regulatory and societal implications of (increased) access
to free knowledge
* Different Modes of Governance: Emergence of Order and Coordination
in Wikipedia
* The role of licensing decisions for Wikipedia and other
collaborative forms of knowledge production
== Submission Guidelines ==
Extended Abstracts must be submitted by the given deadline for peer
review. Conference language is English, exceptions can be made on a
case-by-case basis. Submission entails a commitment that at least one
author will attend the event in the case of acceptance and deliver a
full paper version prior to the event. Also, authors grant the
organizers the right to publish accepted papers in the form of online
proceedings or a similar format, to be determined at a later stage. In
addition, accepted submissions will be automatically licensed under a
Creative Commons Attribution 3.0 Unported license, unless the authors
explicitly state in their submission that they wish to opt out of this
licensing agreement. We encourage authors to use said license in order
to promote open access to scholarly work, although decisions to opt
out will be respected and will not influence the review process in any
way. In any case, authors of accepted submissions cannot opt out from
the basic condition that they grant the organizers the right to
publish at least the extended abstract online.
Please submit your extended abstract (about 2-3 pages) in PDF, Open
Document Format (ODF) or plain text format at:
http://www.easychair.org/conferences/?conf=wpac2012
Note: You will need an easychair account to submit. You can create one
on the spot if you don't already have one.
--
Nicole Ebber
Projektmanagerin
Wikimedia Deutschland e.V.
Eisenacher Straße 2
10777 Berlin
Tel.: +49 30 219158260
http://wikimedia.de
Helfen Sie mit, dass WIKIPEDIA von der UNESCO als erstes digitales
Weltkulturerbe anerkannt wird. Unterzeichnen Sie die Online-Petition:
http://wikipedia.de/wke/.
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.
Har, dug him up from the $(whois mapki.com) email address. Actually
reached him!
ID> Good point. Have you filed this in bugzilla?
Good point. https://bugzilla.wikimedia.org/show_bug.cgi?id=33905
>>>>> "ID" == Ian Dees <ian.dees(a)gmail.com> writes:
ID> Hi all,
ID> Thanks for pointing this out. I've been very frustrated with
ID> Mediawiki's spam protection. Granted mapki.com doesn't really have
ID> any community behind it to help police changes, but Mediawiki sure
ID> doesn't make it easy for a site owner to protect the wiki.
http://mapki.com/wiki/Special:Version looks a little dated though.
ID> To your original question, jidanni, I lost the sitesupport-url a
ID> while back when I was trying to purge spam pages and hadn't bothered
ID> to put it back because it should be fairly easy to see which user
ID> owns the wiki from the changelog (I (User:Yellowbkpk) am the only
ID> one that's making edits).
Er, http://mapki.com/wiki/Sitesupport-url leads to
http://mapki.com/wiki/User_talk:Yellowbkpk leads to nobody home in 2011.
ID> I've since added a "user review" plugin to prevent spam bots from
ID> creating accounts at a rate of 10's per day. This has cut down on
ID> the spam policing I've had to do.
I think you need to reinstall Mediawiki from scratch in a cleanroom...
ID> -Ian
Anyway, my jidanni.org wikis all have 1. my +886-4-25854780 phone number
a mere click or two away, 2. clamped down to "send me an email for an
account", etc. No pretty URLs, but no spam either.
http://abj.jidanni.org/http://radioscanningtw.jidanni.org/http://transgender-taiwan.org/
I'd like to personally thank the technical community for coming
through on this solution. The ISP community has not reported mass
calls to help desks. It really didn't seem too quick and dirty.
I'm a Firefox HTTPS-Everywhere and NoScript kinda guy, and had no
problems switching back and forth by turning scripts on and off.
Both wikipedia and wikimedia js had to be turned on, though.... Why?
Text-only users will even see the big edit notice on the main page!
Next time, please consider adding a textual edit notice to
Special:UserLogin, where the scripts don't load any banner. Perhaps
that could be added to the proposed standard extension?
My guess is there will be a next time. ;-)
Hi,
Today I will be migrating the mailing lists from a very old server (lily) in Amsterdam, to a new server (sodium) in our new Ashburn data center. Mailman will be upgraded to version 2.1.13 along the way.
During the migration, mail will be delayed as all data will need to be transferred to the new host. No mail should go lost, but no new mails will be sent out during the process until done, and the web interface will be unavailable. This shouldn't take more than one hour, if all goes well.
I will report here when things should be back up and running. Afterwards, please let us know of any new issues, in bugzilla or on IRC (#wikimedia-tech). We don't expect any problems, but as with any software upgrade or migration, this can't be guaranteed...
Thanks,
--
Mark Bergsma <mark(a)wikimedia.org>
Lead Operations Architect
Wikimedia Foundation
