So... ( Bear with me a bit )
A couple of days ago, my browsers stopped rendering the {{resolved}}
template properly. The image was showing broken.
Eventually got around to tracking it down, found File:Yes-check.svg
which only exists on Commons now. It was broken when I went to view
it, all the small versions were displaying broken image icon instead
of the checkmark.
I went and clicked on the raw file itself, and it rendered properly,
full sized. After doing that, it was rendering properly at all scales
on all pages.
I don't know if this is a bug in Chrome, a cache bug in the WMF
servers, a rendering bug in the SVG stuff, or what. But I thought it
was wierd enough to report and see if it was just me, or something
wider.
--
-george william herbert
george.herbert(a)gmail.com
Hi.
Is there some reason why the autoreview group (aka autochecked users) is
implicit? It can neither be given to nor taken away from a user by a
sysop/bureaucrat unlike the editor privilege.
Handling the autopromotion to an autochecked user in the same way as to
an editor would IMHO give the project administration more control over
it. For example, someone makes more harm than good - take autoreview
away from them. Someone has been blocked once but their edits are OK -
give it to them. And so on.
And actually I can't see any drawbacks of it but I don't know much about
technical details. Are there some any?
I'm talking with regard to a discussion on Polish wiki, which I have
begun, on enabling autoreview group. The implicitness of it has become
an obstacle.
Regards
lampak
On Fri, Aug 27, 2010 at 2:12 PM, Aryeh Gregor
<Simetrical+wikilist(a)gmail.com<Simetrical%2Bwikilist(a)gmail.com>
> wrote:
> On Fri, Aug 27, 2010 at 4:31 PM, Platonides <Platonides(a)gmail.com> wrote:
>
> [Two reasons to relicense as part of breaking into libraries:]
>
> a) To encourage reuse and
> > b) Avoid debates about using the libraries with other non-GPL code (eg.
> > under PHP license)
>
> The exact same considerations apply to MediaWiki as a whole, though,
> and there are also considerations in favor of GPL. Clearly some
> people prefer BSD, but what does this have to do with breaking code
> out into libraries? It seems orthogonal, so I was puzzled by you
> mentioning it in this particular context. (You can license your files
> as BSD if you like even if they're in MediaWiki core, or at least some
> people have done that.)
It's not strictly orthogonal. It's pretty common practice to have separate
licensing for libraries and other reusable components as opposed to finished
applications. Precedent:
KDE: http://techbase.kde.org/Policies/Licensing_Policy
GNOME: http://live.gnome.org/CopyrightAssignment/Guidelines
Rob
Extension access:
* Jan Paul Posma (janpaul123): Sentence-level editing
* Mikael Lindmark (mikaellindmark): ArticleToCategory2
* Nikola Smolenski (nikola): Interlanguage extension
* Andreas Jonsson (aj): yet another parser project
* Sanyam Goyal (sanyamgoyal): SMW and related extensions
-- Tim Starling
Core access:
* Jacques Roy (jacquesroy7): Informix support.
* Marcin Cieslak (saper): Commonist, pywikipediabot, possibly core
changes such as improved IPv6 support.
Extension access:
* Stephan Gambke (foxtrott): Semantic Forms Inputs.
I am setting up Varnish as a front end cache for a Mediawiki 1.16
installation.
I started with the VCL configuration described here:
http://www.mediawiki.org/wiki/Manual:Varnish_caching
Varnish was not hitting its cache for many requests due to Mediawiki
cookies being in the client request.
Varnish VCL checks for cookies like this:
# Pass requests from logged-in users directly.
if (req.http.Authorization || req.http.Cookie)
{pass;} /* Not cacheable by default */
Digging through the traces and logs I noticed that a client can end up with
Mediawiki cookies without ever having logged into to Mediawiki.
In addtion, Mediawiki does not clear all of its cookies on a logout.
Visiting a Mediawiki login page without even attempting to login
results in a "mw_session" cookie being set. This results in Varnish
treating all subsequent requests as coming from a logged in user
and ignores the Varnish cache.
If you login to Mediawiki, the client ends up with these cookies:
mwUserID=
mwUserName=
mw_session=
After logging out it looks like:
mwUserName=
mw_session=
mwLoggedOut=
So after a logout, the Varnish cache is still ignored.
Its possible to add checks to the Varnish VCL to ignore the spurious
Mediawiki cookies, but
I'm wondering if others have run into the same issue and how they have
addressed it.
Jim
Hi. I'm working on a script which edits a page, adds a section to it and
then redirects to this page.
It would be nice if it went straight to the newly-created section. So I
need to create a link with # in it.
The problem appears when the title of the section contains some
diacritics. For example, link to "bażant królewski" looks like
"Ba.C5.BCant_kr.C3.B3lewski".
How can I generate in JavaScript such a link which would be identical to
the one generated by MediaWiki? Has somebody written such a function? Or
at least, do you know where it is done in MediaWiki php code?
Thanks in advance. And sorry, if it's not the right place to ask this
question.
lampak
PS. Links with numbers (like "#1") will not work in this case, in case
somebody would like to propose it.
-----Original Message-----
Sent: Wednesday, August 25, 2010 10:47 PM
Subject: [FOSDEM] Call for Main Speakers and Devrooms
FOSDEM, the biggest free and non-commercial event organized by and for
the open source community, is taking place in Brussels, Belgium on
Saturday 5 and Sunday 6 February 2011. Apart from having many invited
speakers, the conference offers developer rooms, stands and lightning
talks to projects from the Free and Open source community. This results
in a staggering number of 250+ lectures!
We hereby invite ideas and proposals for main speakers, and proposals
for developer rooms. The call for stands and lightning talks will be
done after announcing the accepted devrooms.
For more details and dates, visit
http://fosdem.org/2011/call_for_mainspeakers_devrooms
Kind regards,
The FOSDEM staff
_______________________________________________
FOSDEM mailing list
FOSDEM(a)lists.fosdem.org
http://lists.fosdem.org/mailman/listinfo/fosdem