Hi Everyone,
Please join me in welcoming Runa Bhattacharjee as the Language Engineering
team’s outreach and QA coordinator. Runa will be responsible for the team’s
language focused technical outreach activities as well as working with
Wikimedia’s language communities to get feedback on internationalization
and localization features being developed or deployed to Wikimedia sites.
Runa started working in the world of open source software as a volunteer
translator for Bengalinux - a community of volunteers working on Indic
language technology during its early years. Runa joins us from Red Hat
where she worked as part of the Localization Services group. At Red Hat she
participated in the development and maturity of Indic language features in
open source enterprise products like Red Hat Enterprise Linux (RHEL). For
the past year she has also helped enhance the latest version of Zanata, an
open source translation platform. She has contributed for many years as a
localizer to several GNOME, Fedora and Mozilla projects.
Runa believes newer platforms and devices used for content delivery and
adoption through local languages make it an exciting time for growth of
open source language tools. She is excited to be part of the Language
Engineering group at Wikimedia Foundation and looking forward to work on
innovations and contributions.
She can be reached on email at runa(a)wikimedia.org or as ‘arrbee’ on our irc
channels including #mediawiki, #wikimedia-dev and #mediawiki-i18n. Her blog
is at arrbee.wordpress.com
Welcome Runa! I am excited to have you on the language engineering team!
Alolita
--
Alolita Sharma
Director of Engineering
Language Engineering
Wikimedia Foundation
Greetings,
Wikimania is six months away - and in terms of planning - that means it is right around the corner.
As such, folks involved with programme and Hackathon organizing are very interested in any ideas that WM developers may have for this year's Hackathon.
Please contribute them on-wiki - https://wikimania2013.wikimedia.org/wiki/Hackathon/Brainstorming
Or if that is just too much wiki for today - feel free to email me and I'll make sure it gets posted. :)
Thank you!
-greg aka varnent
Wikimania 2013 Programme Committee / geek helping with Hackathon
How can an extension have a soft requirement on a module, so that it
only adds that module to its ResourceLoader dependencies if the
extension providing that module is loaded?
For example, there's no sense in depending on ext.eventLog if the wiki
doesn't load Extension:EventLogging, but if it's available then you
want the module sent to the browser along with your code. (Obviously
your JS would check to see if the module's functions are available
before invoking them.)
I think your extension can't change dependencies when specifying its
module in $wgResourceModules[], it has to do it later. Maybe in a
ResourceLoaderRegisterModules hook (although RL runs that before it
registers the static wgResourceModules array), or possibly in a setup
function you add to $wgExtensionFunctions
Or, in each onHook handler where you call addModule(), you could test
there and add the optional module.
Thanks for any insight, I'll add it to mediawiki.org.
--
=S Page software engineer on Editor Engagement Experiments
heya,
for all you Java junkies out there, oh wait there are very few within WMF
:) Anyways, if you do Java you can now use the Nexus Maven repo that is
installed on Labs at http://nexus.wmflabs.org/nexus/index.html#welcome
We are happy to give you an account, please poke us on IRC @
wikimedia-analytics or email David Schoonover or me.
Best,
Diederik
(not sure if this is the right list)
There was the question raised about adding Wikidata pagecount data to the
dumps. As far as I can tell Wikivoyage is already inside the data (although
not described on the description page), but I could not find Wikidata
(maybe I am just missing the right abbreviation, maybe it is not there).
Can someone help with this? Should I make a bug on bugzilla?
Cheers,
Denny
---------- Forwarded message ----------
From: Ed Summers <ehs(a)pobox.com>
Date: 2013/1/28
Subject: Re: [Wikidata-l] getting some stats for the Hungarian Wikipedia
To: "Discussion list for the Wikidata project." <
wikidata-l(a)lists.wikimedia.org>
On the subject of stats are there any plans to add wikidata access stats to:
http://dumps.wikimedia.org/other/pagecounts-raw/
Or are they available elsewhere?
//Ed
On Mon, Jan 28, 2013 at 10:31 AM, Nikola Smolenski <smolensk(a)eunet.rs>
wrote:
> On 28/01/13 15:39, Lydia Pintscher wrote:
>>
>> Is anyone interested in getting us some stats for the deployment on
>> the Hungarian Wikipedia? There is a database dump at
>> http://dumps.wikimedia.org/backup-index.html from the 22nd of January
>> that could be used. I'm interested in the effect Wikidata had so far
>> on this one Wikipedia.
>
>
> Not from dumps, but from Toolserver, I don't see some reduction in bot
> activity. Number of bot edits in last 12 months:
>
> 201201 61527
> 201202 48472
> 201203 55553
> 201204 60875
> 201205 56364
> 201206 56483
> 201207 49836
> 201208 50862
> 201209 39235
> 201210 44943
> 201211 37492
> 201212 52815
> 201301 40258
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
--
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.
Hi all,
I would like to ask some help to do one thing and brainstorm a little
about some tools for crowdsourcing wikimedians ideas.
1) My first question is if someone could help me to create a RSS feed
of threads of the Portuguese Wikipedia village pump (= /esplanada/).
The feed would contain the title and link to the thread, the thread
body and the author. Our /esplanada/ has one subpage per thread, which
makes easy to watch what I want. See bellow
http://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Esplanada/geral
But I miss sometimes topics being created only using my watchlist and
a RSS feed would facilitate my life to read and follow all threads I
am interested in using an aggregator or even making the feed send each
thread by e-mail. Once I created a RSS feed using a Web service that
found HTML patterns, so I think that could be done in a similar way (I
cannot remember the service name now). Would be easy to create a
Python script for that? (maybe with beautifulSoup?) Any other method
suggestion?
2) Not only for reading purposes, I also would like to add this
threads and possible ideas inside the discussion on systems like All
our ideas <http://www.allourideas.org/>, OSQA <http://osqa.net> (see
this example <http://ideas.okfn.org/>) or possible other softwares to
evaluate the best ideas and threads using a crowdsourcing model -
other ideas for tools welcome.
Any help for 1 and any idea for 2 is welcome. Thanks,
Tom
--
Everton Zanella Alvarenga (also Tom)
"A life spent making mistakes is not only more honorable, but more
useful than a life spent doing nothing."
Hello,
Last January 12, some web technology enthusiasts attend the first MediaWiki
meetup / orientation in Makati City, Philippines.
Here is the photo from fb:
https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-prn1/71495_10151206726144…
Part of the things discussed is having a workshop for aspiring developers.
Since our community is in its infancy and there is scarcity of subject
matter experts, may we ask your assistance in planning and developing this
outreach workshop.
Part of the assistance include:
1. Having a resource speaker / guru to train and assist our future local
tech trainers
2. Creation of a workshop module that include exercises and practice tests
Depending on the outcome of our plan, we are targeting to have this started
this April in time on our Summer break. Summer in the Philippines coincides
with Spring in other places in the northern hemisphere.
Thank you.
--
Butch Bustria
Manila, Philippines
------------------------------
The information contained in this message is privileged and intended only
for the recipients named. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message or
the information it contains is prohibited. If you have received this
message in error, please immediately notify the sender, and delete the
original message and attachments.
Please consider the environment before printing this email.
*********************************************************************
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 for the Semantic MediaWiki Conference 'SMWCon
Spring 2013'.
WHERE
The Spring 2013 SMWCon will be held at Interactive Telecommunications
Program (or ITP),
a department of New York University, in New York City, in the United States.
ITP is an incredibly creative place, located at 721 Broadway, between
Washington Pl. and
Waverly Pl., in New York's Greenwich Village neighborhood.
WHEN
March 20-22 2013.
CONFERENCE WEBSITE:
http://semantic-mediawiki.org/wiki/SMWCon_Spring_2013
This will be the 10th edition of the Semantic MediaWiki Conference!
SMWCon is open to everyone interested in collaborative knowledge creation
using semantic wikis.
The event brings together developers, users, and organizations from the
Semantic MediaWiki
community around the world.
In what is becoming a tradition, we will spend the first day with tutorials
and a workshop for
those who want to learn more about Semantic MediaWiki and build from it.
The second and
the third day of the conference will include talks from the developers and
users of SMW.
HOW TO PARTICIPATE
We have started to form a program of the conference.
Since this is a community driven event, please visit the following wiki
page to get news
about the program, add your name to the attendees list and register your
talk:
http://semantic-mediawiki.org/wiki/SMWCon_Spring_2013
It does not have to be formal and/or complete, however, you're welcome to
share more
information about your talk, like a short abstract, and even desirable
length. We are looking
for use cases, updates on existing projects, lightning talks, or even demos.
IMPORTANT DATES
February 20 - deadlines to submit proposals of talks (the earlier the
better)
March 20 - the conference itself
See you in New York!
Regards,
Laurent Alquier, Program Chair
After talking to some of you at the office on Friday (was great, thanks!),
and reading some new suggestions (thanks Brion), it seems API has gained
several distinct, slightly overlapping areas of operation.
* SQL-like: This is what the API is best at - providing complex structured
access to the database - various page properties and lists like "what pages
link to X". The prime beneficiaries are bots (spam fighting, link/iw
fixing, etc). Required improvements are fairly cosmetic in nature -
minor refactoring, warning/error localization, per module versioning (see
RFC <http://www.mediawiki.org/wiki/Requests_for_comment/API_Future>).
* Actions (MasterDB changes): API has greatly grown in this area, providing
access to most MW functionality like editing, uploading, watching, account
creation, etc. Some cleanup work might still be required, i.e. better token
management, but overall this portion is also fairly mature.
* Content - wiki markup/html/sub-sections - this area seems to need
improvements the most, due to the much wider variety and style of uses and
the potential server load.
For example, mobile requires quick access to rendered individual sections
of an article, a web site might embed the page header, a javascript clients
might want some pieces of information specific to the given site - text
from some table, template parameters, and many other - this list *needs to
be expanded* for better planning, ideally at the RFC
page<http://www.mediawiki.org/wiki/Requests_for_comment/API_Future>
.
Unlike query, content-access rarely requires multi-source aggregated
results, yet has a much higher usage load, making it the primary target for
caching. In my opinion, this difference is the root of misunderstanding
between the REST and the current API style advocates.
This brings us to how we want to grow the "content API", assuming that
caching is by far the most important concern:
* JSON-only output
* Minimum number of parameters
* URL rewriting
Most improvements for querying and actions are listed at
http://www.mediawiki.org/wiki/Requests_for_comment/API_Future and are
currently being worked on, but the content approach needs use cases,
requests, and interface suggestions.
