Hi all,
We have a longstanding request to enable HTML5 on all sites:
https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
We've had it enabled on mediawiki.org for ages, with minimal death and
mayhem. There are two issues listed as blockers:
Bug 30525: Search bar icon/button slightly lower when html5 mode is enabled
https://bugzilla.wikimedia.org/show_bug.cgi?id=30525
Bug 36495: Sanitizer incorrectly converts align="right" for elements
that are not table-cells
https://bugzilla.wikimedia.org/show_bug.cgi?id=36495
Bug 30525 doesn't seem like a blocker to me (but patches definitely
welcome). Bug 36495 seems more likely to cause problems, though I'd
like to nudge Krinkle to explain Comment 9.
Assuming we can either get these fixed, or agree they aren't blockers,
I say we set a date and go. Should we plan on sometime in July (say a
week or two after Wikimania)?
Rob
Hi everyone,
I've just come across (and enabled) a feature in Gerrit that I think
many will find useful. I'm calling them "personal sandboxes." The
basic premise is that each user can have a personal branch space
that they have push rights to that don't require admin intervention.
The branches are named in the format "sandbox/$username/*" so I
could make a sandbox called "sandbox/demon/weekend-hacking"
and push that to gerrit without requiring review or anyone to make
the branch first. Quick example:
$ cd mediawiki/core
$ git checkout -b sandbox/demon/foo-bar
[ hack away ]
$ git push --set-upstream origin sandbox/demon/foo-bar
(The --set-upstream is only necessary the first time you push)
This isn't designed to replace long-lived branches where you are
collaborating with others, but to simply give you a space where you
can push some work when you want to stash it (and it should be
viewable by Gitweb, if you want others to see it).
Happy hacking!
-Chad
Hello again!
As before, I have a test instance of MediaWiki and Etherpad Lite
running, and I'm looking for people to help me test an extension that
ties them together!
If you're interested in testing the extension without any setup, you can
just head over to my TestWiki [0]. If you'd like to get the extension
set up on your own, you can try the Extension page [1] for more
instructions.
There is a long list of new features, probably the most notable are:
* Fork pads! Yes, multiple pads per wiki page!
* Prettier, and more numerous, formatting buttons!
* More robust authentication via a new Etherpad Lite plugin!
* "Collaborate" button!
* Auto-fork when you click "Collaborate" on a page that has been edited
since the last pad was created!
* Kick users who are annoying from a pad you created!
So, feel free to test. If something seems a little wonky, or outright
doesn't work, please do file a bug report on Bugzilla [2].
Thanks again for the help! Oh, and I've registered #ethereditor on
Freenode, in case people would like to join there rather than file bug
reports. I'm usually online in IRC 100% of the time, though not
necessarily at the keyboard. I'll be around at least from 16:00 to 17:00
and from 23:00 to 00:00 GMT every weekday.
If you act now, I'll throw in an Etherpad Lite instance [3] that edits
wikitext, though you cannot set or change your username from its
interface. This could be useful for temporary sessions of editing wiki
pages collaboratively, if people were interested in that sort of thing.
[0] TestWiki - http://etherpad.wmflabs.org/wiki/index.php/Main_Page
[1] Extension:EtherEditor -
http://www.mediawiki.org/wiki/Extension:EtherEditor
[2] Bugzilla -
https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…
[3] Etherpad Lite instance - http://etherpad.wmflabs.org/pad/
--
Mark Holmquist
Contractor, Wikimedia Foundation
mtraceur(a)member.fsf.org
http://marktraceur.info
Hi all,
we are trying to let users switch their language - whether they are
logged in or not - through a language selector. This can be either the
ULS, which is progressing impressively, or just a list of languages in
the sidebar, or anything else. After selecting it, the page is
rerendered using the uselang parameter.
Now the problem: the uselang parameter is not sticky. When I move to
another page, it is lost.
We tried to change the linker in order to add the uselang parameter
every time -- but it only works in the content, not in the sidebar and
actionlinks.
We could put the language into a cookie, as the ULS currently does,
but this means that the squid caches won't work, afaik.
We could take the output just before it is send to the browser and
regex-substitute all the links in order to add the uselang parameter
every... OK, half joking. Only half.
Another solution could be to put the language into the path, i.e. the
pretty URL /wiki/San_Franicisco does get rewritten to
/w/index.php?title=San_Francisco as of now, but change that to
/hr/San_Francisco rewritten to /w/index.php/San_Francisco?uselang=hr
(or /w/index.php/Special:UseLang/hr/San:Franciso with an Alias if this
is more pleasing)
I think this is based on an idea of Brion during the Hackathon.
So switching the user language amounts to change the URL.
Any comments on this?
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
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.
*********************************************************************
We apologize if you received multiple copies of this Call for Papers.
Please feel free to distribute it to those who might be interested.
*********************************************************************
This is an announcement of Semantic MediaWiki
Conference 'SMWCon Fall 2012'.
WHERE
Cologne (Köln), Germany,
WHEN
October 24-26 2012.
CONFERENCE WEBSITE:
http://semantic-mediawiki.org/wiki/SMWCon_Fall_2012
SMWCon is an event for everyone who is interested in collaborative
knowledge creation and semantic wikis. If you use SMW in your projects
or want to know how it can be applied to your needs or want to discuss
the future of the project, SMWCon is a right place to go.
As always, in the first day we will have some introductory tutorials for
those who want to learn more about Semantic MediaWiki. The second and
the third day of the conference will include talks from the developers
and users of SMW.
We also will have some talks about Wikidata project and Semantic
MediaWiki roadmap.
HOW TO PARTICIPATE
We have started to form a program of the conference.
To register or write the abstract of your talk you should edit
the page http://semantic-mediawiki.org/wiki/SMWCon_Fall_2012.
IMPORTANT DATES
September 24 - proposal on a wiki (the earlier the better)
October 24 - the conference itself
See you in Cologne!
Sincerely yours,
Yury Katkov, program chair
Hello!
I thought I'd reach out to the wider wikitech community to discuss a
problem we are having in the MobileFrontend extension and see if
anyone can come up with a good solution.
The MobileFrontend extension is increasingly getting [1] bugs [2]
raised [3] which are due to inline css styles present in certain wiki
articles that are written with the desktop site in mind. (Slightly off
topic there is also certain content that just doesn't work on mobile
[4])
To get an idea of some of the bugs that are present please see this bug [5].
Currently we are resorting to various !important hacks in a separate
css file [6] but this is not sustainable and does not cover everything
and ideally I would prefer that this file was not needed at all.
Solutions I have thought about so far involve the following. I am yet
to conclude on which is the best way to do this so would really
appreciate discussion...
1) scrubbing all inline styles
#########################
* in php - my worry is this would be a quite expensive operation?
* in javascript (but this doesn't help people with javascript disabled)
* would mean any nice mobile safe styling disappears :(
2) scrubbing certain inline styles
#########################
* I could imagine us scrubbing any inline styles which have not been
marked as mobile safe (e.g. anything with a class 'mobilesafe' keeps
its inline style) - this at least allows editors to use pretty styles
and encourages checking their styles on mobile
3) disallowing inline styles in wikitext output
##################################
* this is controversial as it would restrict us to defining css rules
in MediaWiki:Common.css which only admins can edit
** one could imagine pages/templates being able to maintain their own
stylesheets for desktop and mobile to allow customisations
** ResourceLoader could serve the desktop or mobile stylesheet
depending on the context
4) educating editors better about ensuring their styles work on mobile
#############################################
I'm not sure how effective/sustainable this would be and how we'd go
about doing this... but would be keen to hear your thoughts around it.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=30887
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=36030
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=36076
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=20030
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=35704
[6] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend…
> How can I prevent this conversion so ampersands (and presumably other special characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact that it's a parser tag extension. Simply returning "&" in the callback will produce "&". Is there a way to suppress this conversion when returning "&" from a parser tag extension?
DanB
Hi!
I'm trying to register the second e-mail in Gerrit, right here:
https://gerrit.wikimedia.org/r/#/settings/contact
I have the following application error:
Cannot format velocity template
com/google/gerrit/server/mail/RegisterNewEmail.vm
Is that a bug?
Sincerely yours,
Yury Katkov
In a parser tag callback, if I change this:
function myCallback($input, $argv, $parser) {
return '&';
}
to this:
function myCallback($input, $argv, $parser) {
return array('&', 'markerType' => 'nowiki');
}
shouldn't the second one cause a plain ampersand to be rendered, rather than & ?
Reference: http://www.mediawiki.org/wiki/Manual:Tag_extensions#How_can_I_avoid_modific….
This is MediaWiki 1.18.1.
Thanks,
DanB
_____________________________________________
From: Daniel Barrett
Sent: Friday, June 29, 2012 3:42 PM
To: 'Wikimedia developers'
Subject: RE: StripState and ampersands?
> How can I prevent this conversion so ampersands (and presumably other special characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact that it's a parser tag extension. Simply returning "&" in the callback will produce "&". Is there a way to suppress this conversion when returning "&" from a parser tag extension?
DanB
Hey,
I am writing some code that needs to be executed on every article deletion
and which needs the latest revision of the article that was deleted. Is
there any place (hook) where I can put this without doing a db read for the
revision? And if not, is there any place where I can put this where I
actually get the revision id I need or can obtain it without writing my own
query?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--