Hi,
I have created a proof of concept of this, which contains the
information only for categorymembers. The code is at [1] and it looks
something like this (XML formatted):
<props>
<prop name="ids">
<properties>
<property name="pageid" type="integer" />
</properties>
</prop>
<prop name="title">
<properties>
<property name="ns" type="namespace" />
<property name="title" type="string" />
</properties>
</prop>
<prop name="type">
<properties>
<property name="type">
<type>
<t>page</t>
<t>subcat</t>
<t>file</t>
</type>
</property>
</properties>
</prop>
</props>
What do you think?
One problem I'm aware of is that the output uses “prop” and “property”
to mean something else. Do you have any suggestions for better naming?
After this, I will add the necessary information to the rest of the
API modules and then post a patch to bugzilla.
[1] https://github.com/svick/mediawiki/commit/868910637445ea0dcf3ad84bc1ee9fc33…
Petr Onderka
[[en:User:Svick]]
On Thu, Nov 10, 2011 at 11:37, Roan Kattouw <roan.kattouw(a)gmail.com> wrote:
> On Wed, Nov 9, 2011 at 11:36 PM, Petr Onderka <gsvick(a)gmail.com> wrote:
>> Is this information available somewhere? Is trying the query and
>> seeing what properties are returned the best I can do currently?
> Unfortunately, no, at least not programmatically.
>
>> Do
>> you think it would be a good idea if I (or someone else) modified
>> “action=paraminfo” to include this information in some form?
>>
> Yes, please do! Patches are very welcome.
>
> Roan
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Hey All,
There's a somewhat urgent issue being discussed on English Wikipedia at the
moment relating to offensive emails from a certain domain.
Discussion is here.<http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incide…>
I wonder if any ops people are able to quickly address this, perhaps by
blacklisting a domain (or specific email addresses) server side. Obviously
harassment of editors is a big problem so I 'm going for a pro-active "find
someone to fix it" approach :)
If not, anyone have suggestions?
Tom
Our wfArrayToCGI and wfCgiToArray conversion functions (they transform
data between 'foo=bar&hello=world' and array( 'foo' => 'bar', 'hello' =>
'world' ) formats) seam to be fairly messed up.
In a discussion over r104518 on the way it did query parameters to pass to
getLocalURL I noticed our lack of sane null handling in wfArrayToCGI.
However after examining it even more I found that the output of this area
of code seams completely messed up.
Some examples of how these behave:
> echo wfArrayToCGI(array('foo' => 'bar', 'baz' => '', 'asdf' => null,
> 'qwerty' => false));
foo=bar&asdf=&qwerty=
# In array -> cgi conversion we will omit a key for an empty string, but
yield an empty value for null and false
# Frankly it should be the other way around. An empty string is reasonable
input to expect an empty but present cgi key.
# By the way, this is our treatment of an empty value in our method that
goes in the opposite direction
> var_dump(wfCgiToArray('foo=bar&asdf='));
array(2) {
["foo"]=>
string(3) "bar"
["asdf"]=>
string(0) ""
}
# Naturally you can expect how a round trip is screwed up
> var_dump(wfArrayToCGI(wfCgiToArray('foo=bar&asdf=')));
string(7) "foo=bar"
# Because we treat an empty string as an omission instead of a value the
round trip omits something we had in the first place
# cgi to array conversion could use some proper handling of an edge case
too
> var_dump(wfCgiToArray('foo=bar&asdf=&qwerty'));
PHP Notice: Undefined offset: 1 in
/Users/daniel/Workspace/mediawiki/trunk/phase3/includes/GlobalFunctions.php
on line 388
array(3) {
["foo"]=>
string(3) "bar"
["asdf"]=>
string(0) ""
["qwerty"]=>
string(0) ""
}
# Personally I think that 'foo=bar&asdf=&qwerty' should yield an array like
# array( 'foo' => 'bar', 'asdf' => '', 'qwerty );
Does anyone think anything would break if I re-coded these two deep core
methods to work in a seemingly more sane way.
[r104518] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104518
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
At the GLAMCamp DC (February 10-12, Washington, DC, USA), we will be
working on improvements to Wikimedia technology -- see
https://meta.wikimedia.org/wiki/GLAMcamp_DC#Tasks . Specifically, the
GLAM folks are working on better mass upload tools for museums to use,
better reporting metrics, and building a glamwiki.org website. If you
want to help, let them know you're interested in attending. More info
below.
(I'll almost certainly be there, and it looks like at least one or two
other Foundation folks will be as well.)
best,
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
-------- Original Message --------
Subject: [cultural-partners] GLAMcamp DC
Date: Wed, 30 Nov 2011 20:08:03 -0500
From: Lori Phillips <lori.byrd.phillips(a)gmail.com>
Hello everyone,
On the cusp of GLAMcamp Amsterdam, we’re excited to announce that GLAMcamp
DC will be hosted by the National Archives and Records Administration from
February 10-12, 2012.
As with past GLAMcamps, GLAMcamp DC will be a meeting/workshop for
Wikimedians active in outreach within cultural institutions (as well as for
those interested in becoming more active.) The event will target a small
group of community-focused and technology-focused Wikimedians in the United
States who will continue and solidify the key elements of the GLAM-Wiki
project.
What makes this GLAMcamp different is its focus on the US. This event will
essentially serve as the kicking off of US GLAM-Wiki organization, and will
help to fine tune the scope and goals of the US Cultural Partnerships
Coordinator and associated projects. One of the primary goals of GLAM-Wiki
in the US is to establish a formal listing of volunteers that can be called
upon to assist GLAMs, and this event will do much to galvanize such a group.
GLAMcamp DC will of course continue the good work that comes out of
GLAMcamp Amsterdam and will work to further improve the tools and
documentation associated with the wider GLAM-Wiki community.
While all are welcome to apply to attend, there are a limited number of
spots available. Please go here to apply:
http://meta.wikimedia.org/wiki/GLAMcamp_DC/Application
Or see the event planning page for more details:
http://meta.wikimedia.org/wiki/GLAMcamp_DC
Thanks so much,
Lori Phillips [[User:LoriLee]]
Sarah Stierch [[User:SarahStierch]]
Pete Forsyth [[User:Peteforsyth]]
--
Lori Phillips
Web Content Specialist | Wikipedian-in-Residence
The Children's Museum of Indianapolis
(phone number elided by Sumana) http://loribyrdphillips.com/
Hey all.
I'm looking for comments regarding an extension I knocked up today and its
viability for Wikimedia wikis:
https://github.com/Jarry1250/TranslateSvg
The extension removes the need for duplicating a file (an administrative
nightmare) when you want to translate it. It does this by creating an extra
information flow:
[[File:Example.svg|thumb|120px|lang=en]] => rsvg "...Example.svg"
"120px-en-Example.svg" (lang='en') => Displays in English
[[File:Example.svg|thumb|120px|lang=fr]] => rsvg "...Example.svg"
"120px-fr-Example.svg" (lang='fr') => Displays in French
It means rsvg SVG to PNG will finally "understand" the <switch> tag,
enabling fully translatable SVGs [1]. It would eventually work in tandem
with a translating interface, e.g. through TranslateWiki and/or a local
special page.
The only issue I know of is that the renderer will create a new file every
time you change the language parameter, causing a drain on memory/storage
space. How do we handle this for random thumb sizes at the moment?
All comments appreciated
Harry (User:Jarry1250)
[1] https://developer.mozilla.org/en/SVG/Element/switch
Why do we have callgraph images in the documentation? I can't
understand how they are useful, and they eat bandwidth (+ screenspace)
unnecessarily. Is there a reason for their existence? Can we get rid
of them?
Check this for an example: http://svn.wikimedia.org/doc/classLinker.html
--
Yuvi Panda T
http://yuvi.in/blog
https://bugzilla.wikimedia.org/show_bug.cgi?id=32879
I recommend we go ahead and update for 1.19 before branch time; there's bug
fixes and it doesn't appear to drop support for anything we'd want. Any
objection?
-- brion
There's a fairly new website called SocialCoding4Good that aims to match
mature free/open source projects with experienced developers who want to
volunteer. They've invited us to be part of the pilot.
http://socialcoding4good.org/
Specifically, in the pilot phase, SC4G will suggest open source tasks to
experienced engineers who are taking paid sabbaticals (sometime in
spring 2012) from their R&D jobs at VMWare. We and 3-4 other nonprofits
are asking to host some of their engineers. I have suggested some
tasks, both for 1-week stints and for 3-month engagements.
http://socialcoding4good.org/organizations/wikimedia
Like Google Summer of Code interns and most OpenHatch entrants
<http://openhatch.org/+projects/MediaWiki>, these engineers will be new
and will require mentorship. Unlike GSoC students, these are
experienced developers, so I feel comfortable mentioning some of our
larger and hairier TODOs, like the visual editor, extension management,
and metaschema work.
I already submitted this page to VMWare (because of their deadlines) but
I welcome suggestions for other stuff to put on it, for the post-pilot
phase.
https://www.mediawiki.org/wiki/Annoying_large_bugs seems like the best
wiki page to put those suggestions on. I'll merge stuff together when
more stuff is on the wiki page.
And I'll be chasing you all to volunteer for mentorship in the spring,
too. :-)
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
