Hi,
I am Pawan Kumar D. I am a final year Computer Sciene student from IIT
Roorkee, India.
More info on me can be found my user
page<https://www.mediawiki.org/wiki/User:Pawanseerwani_1>
.
I intend to work on a GSoC project under this organization.
I have made a proposal for the following project : Simultaneous
Modification of Multiple Pages with Semantic
Forms<https://www.mediawiki.org/wiki/Google_Summer_of_Code_2014#Simultaneous_Modi…>
Do go through the project .
I would be happy to answer any queries or suggestion on the project here
but I would appreciate if it could be done at the corresponding discussion
page<https://www.mediawiki.org/wiki/User_talk:Pawanseerwani_1/GSoC_proposal> so
that its all at one place and can be easily accessible.
Thanks,
Pawan kumar D
IIT Roorkee
ᐧ
Hello everyone!
I am Pratik Lahoti (User:BPositive) from Pune, India. I am willing to
participate in the Google Summer of Code this year. I am interested in the
project titled - "Tools for mass migration of legacy translated wiki
content<https://www.mediawiki.org/wiki/Summer_of_Code_2014#Tools_for_mass_migration…>
".
My mentors for this project would be Niklas
Laxström<https://wikimediafoundation.org/wiki/User:Nlaxstrom>and
Federico
Leva <https://meta.wikimedia.org/wiki/User:Nemo_bis>.
With their help, I have drafted the first version of my proposal page. You
can find it here:
https://www.mediawiki.org/wiki/Extension:Translate/Mass_migration_tools
Brief overview of the project:
The MediaWiki Translate
extension<https://www.mediawiki.org/wiki/Extension:Translate>makes the
task of translation easier by providing a user-friendly interface
that consists of text strings splitted into translation units.
Non-translatable content like images are excluded from the process of
translation. Though that makes the job easy with a rich editor supporting
various languages, a lot of effort is required to prepare the page for
translation, i.e, the page under question first needs to be converted into
a format that would be recognized by the Translate extension. The process
of preparing the page for translation needs to take into consideration
various markups<https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_ad…>which
becomes a tedious task when done manually. Plus, wikis have a lot of
legacy content that still needs to be made translatable.
Thus, with this motivation, the project aims to facilitate this conversion
and thereby save manual time and effort. The tool developed would thus make
the page translatable, and once that is done, it would import the
translations (which were present before the page was made translatable)
into the Translate extension. Thus, the entire process of importing
translations which involved a significant amount of manual task gets
automated by this project.
The proposal page mentions the Project Outline and the approach/solution
towards the problem statement. I am done with most of the sections and left
with the Project Schedule (which I will finish off when everything is
finalized).
Please have a look at the proposal and give your valuable
feedback/suggestions. While I have no problems in replying to the
suggestions put forth over here, I would appreciate if you can do the same
on the discussion
page<https://www.mediawiki.org/wiki/Extension_talk:Translate/Mass_migration_tools>of
the proposal, so that all the feedback is at one single place.
Looking forward to the inputs from the community.
--
Warm Regards,
*Pratik Lahoti*
User:BPositive <https://www.mediawiki.org/wiki/User:BPositive>
Hi all,
I'm Maduranga Siriwardena, 3rd year computer Science and Engineering
Undergraduate at University of Moratuwa, Sri Lanka. Currently I'm in my
internship at WSO2, which a opensource middleware company.
While going through the project ideas, the idea of "A system for reviewing
funding requests" impressed me. But as I'm new to the wikimedia project, I
don't have much idea how to proceed. Please describe the requirements of
the project and other requirements needed to proceed with this project.
Thank you
--
Maduranga Siriwardena
Undergraduate
University of Moratuwa, Faculty of Engineering
Department of Computer Science and Engineering
I don't even know what the purpose of this thread is now. Seems to be
discussion about development practices, badgering and various other things.
I started two other threads to try and break out these important
conversations but looks like conversation is still happening here so I
guess that failed.
I figure a lot of people have muted this thread now (myself included now).
It would be great if we could turn all this anger and frustrations into
solutions to fix some of the root issues here. My personal opinion is I
doubt any of this will happen on this thread.
On 8 Mar 2014 22:04, "Ryan Lane" <rlane32(a)gmail.com> wrote:
> On Sat, Mar 8, 2014 at 9:34 PM, MZMcBride <z(a)mzmcbride.com> wrote:
>
> > Chad wrote:
> > > On Mar 8, 2014 1:42 PM, "Brandon Harris" <bharris(a)wikimedia.org>
> wrote:
> > >>https://en.wikipedia.org/wiki/Badger
> > >
> > >New rule: calling badger is synonymous with asking for the moderation
> bit
> > >for yourself.
> >
> > Fine, but first we have to ban the people who top-post and don't trim
> > unnecessary parts of their e-mails. :-)
> >
> > I personally read the badger link as a politer(?) version of calling
> > someone a troll.
> >
> >
> It's actually something used on WMF staffer lists and it's supposed to be a
> cute way of telling people a thread is getting out of hand. Some people use
> it that way, and I feel Brandon was in this case, but it's most often used
> to shut down conversations that people find unpleasant or controversial and
> its actual effect is usually to enrage those it's used against.
>
> I'd wager it has an overwhelmingly negative effect on communication (and
> WMF's internal politics likely prove that) and I'm with Chad in saying
> anyone that uses it here should be moderated. This is of course off topic,
> so I'll leave this at that.
>
> - Ryan
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi all,
the multimedia team [1] had a chat about some architectural issues with
MultimediaViewer [2] today, and Robla has pointed out that we should
publish such discussions on wikitech-l to make sure we do no reinvent to
many wheels, so here goes. Comments pointing out all the obvious solutions
we have missed are very welcome.
== Use of OOjs-UI ==
Mark experimentally implemented a panel showing share/embed links [3][4] in
OOjs-UI [5]; we discussed some concerns about that. We want to avoid having
to roll our own UI toolkit, and also don't want to introduce yet another
third-party toolkit as the list of libraries loaded by some Wikipedia
extension or other is already too long, and the look-and-feel already too
fractured, so we would be happy to free-ride on another team's efforts :)
On the other hand, OOjs-UI is still under development, does not have tests
and has very little documentation, and the browser support is less than we
would prefer. We could contribute back in those areas, but it would slow us
down significantly.
In the end we felt that's not something we should decide on our own as it
involves redefining the goals of the team somewhat (it was a developer-only
meeting), so we left it open. (The next MultimediaViewer features which
would depend heavily on a UI toolkit are a few months away, so it is not an
urgent decision for us.)
== The state of unit tests ==
MultimediaViewer used to have a messy codebase; we felt at the time that it
is better to have ugly tests than no tests, so we ended up with some large
and convoluted tests which are hard to maintain. Since then we did a lot of
refactoring but kept most of the tests, so now we have some tests which are
harder to understand and more effort to maintain than the code they are
testing. Also, we fixed failing tests after the refactorings, but did not
check the working ones, we cannot be sure they are still testing what they
are supposed to.
We discussed these issues, and decided that writing the tests was still a
good decision at the time, but once we are done with the major code
refactorings, we should take some time to refactor the tests as well. Many
of our current tests test the implementation of a class; we should replace
them with ones that test the specification.
== Plugin architecture ==
We had plans to create some sort of plugin system so that gadgets can
extend the functionality of MultimediaViewer [6]; we discussed whether that
should be an open model where it is possible to alter the behavior of any
component (think Symfony2 or Firefox) and plugins are not limited in their
functionality, or a closed model where there are a limited number of
junction points where gadgets can influence behavior (think MediaWiki hook
system, just much more limited).
The open model seems more in line with Wikimedia philosophy, and might
actually be easier to implement (most of it is just good architecture like
services or dependency injection which would make sense even if we did not
want plugins); on the other hand it would mean a lot of gadgets break every
time we change things, and some possibly do even if we don't. Also, many
the community seems to have much lower tolerance for breakage in
WMF-maintained tools breaking than in community-maintained tools, and most
people probably wouldn't make the distinction between MultimediaViewer
breaking because it is buggy and it breaking because a gadget interacting
with it is buggy, so giving plugins enough freedom to break it might be
inviting conflict. Some sort of hook system (with try-catch blocks, strict
validation etc) would be much more stable, and it would probably require
less technical expertise to use, but it could prevent many potential uses,
and forces us to make more assumptions about what kind of plugins people
would write.
Decision: go with the closed model; reach out for potential plugin writers
and collect requirements; do not guess, only add plugin functionality where
it is actually requested by someone. In general try not to spend too much
effort on it, having a useful plugin system by the time MultimediaViewer is
deployed publicly is probably too ambitious a goal.
[1] https://www.mediawiki.org/wiki/Multimedia
[2] https://www.mediawiki.org/wiki/Extension:MultimediaViewer
[3] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/147
[4] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/148
[5] https://www.mediawiki.org/wiki/OOjs_UI
[6] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/168
On 03/08/2014 02:10 PM, Isarra Yos <zhorishna(a)gmail.com> wrote:
> On 08/03/14 09:15, Niklas Laxström wrote:
>> Please do not forget the contributors who want to improve MediaWiki
>> for their own needs. We also have to balance how much we inconvenience
>> them to meet the requirements of WMF. In my opinion, the balance is
>> already in favor of WMF.
>>
>> -Niklas
>
> This.
>
> MediaWiki serves many interests, and it's already hard enough for
> third-party users to contribute their features/improvements upstream
> that most simply don't even try. We should be trying to improve this,
> not make it even worse for them, because these are often things that
> would prove widely useful even if they are not /currently/ WMF
> priorities (it is not uncommon for them later become such and then have
> to be completely reimplemented).
+1.
BTW, anyone care to have a look at
https://gerrit.wikimedia.org/r/#/c/67173/3
? :)
(It's been sitting around for a good while, and it would make my life
tons easier if it could get into the 1.23 LTS.)
LW
Le 07/03/2014 19:25, Asaf Bartov a écrit :
> btw, are these new improved tools documented anywhere?
> http://kiwix.org/wiki/Development does not seem to point in the right
> direction.
The usage is pretty straightforward (for IT people) and IMO everything
necessary is explained in the READMEs:
* mwoffliner:
https://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner/
* zimwriterfs:
https://sourceforge.net/p/kiwix/other/ci/master/tree/zimwriterfs/
NB: The goal is not that everybody creates its own full wikipedia ZIM
file. The goal is that we (Wikimedia) provide these files, often enough
to always have up2date ZIM information (so at least one time per month).
Thus, the challenge is now to setup an infrastructure similar to the one
which creates the XML dumps.
Emmanuel
PS: We really want to make a post @blog.wikimedia.org (so in English).
If someone is volunteer to write this, I would really appreciate his help.
--
Kiwix - Wikipedia Offline & more
* Web: http://www.kiwix.org
* Twitter: https://twitter.com/KiwixOffline
* more: http://www.kiwix.org/wiki/Communication
Minutes and slides from Wednesday's quarterly review of the
Foundation's Wikipedia Zero team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We'll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We're slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
On 8 mrt. 2014, at 00:47, Russell Nelson <russnelson(a)gmail.com> wrote:
> Maps great, yes. Here's what *I* think Wikipedia needs. First and foremost, OSM is a database, just like Wikipedia articles are data (don't get me started). It's a foreign database, which means that you have the foreign key problem. Wikipedia articles all have a published unique name. Perfect for a foreign key. Articles can get moved, but in the ordinary course of editing, they don't. In OSM, the key "wikipedia" is used to make reference to a Wikipedia article. It can be the full URL, or simply the article name (latter is recommended). http://wiki.openstreetmap.org/wiki/Key:wikipedia for details.
I agree, somewhat, but I think this is not 'Wikipedia' per se. It's as much a need for OSM, as it is a need for Wikipedia. And articles do get moved (as much as OSM nodes with tags on them get deleted).
> Linking to OpenStreetMap entities, on the other hand, is somewhat more abstract. OSM entities (nodes, ways, and relations, all fruitful for Wikipedia linking) have a database ID. The trouble that the ID is only as persistent as the database entry, which can change through as simple a change as adding a bridge to a road (one database entry becomes three -- the original, a new short one which is the bridge, and the remainder of the road, as a new way). Probably the most persistent way to link to an entity is to give a lat/lon of a node, and give the name of the node. That is enough information to recover from any editing (if the node gets moved or deleted, there be congruent nodes nearby, and if the name is changed, you still have the node's location). Particularly if the entity has a Wikipedia article name; a bot can audit both databases against each other.
> Wikipedia currently has only points in articles. At most you can say "The subject of this article is at this point." which is insufficient if the point is an area (in OSM, a self-terminating way), a way (e.g. road, railroad, river), or a relation (a collection of related ways, e.g. a lake and its islands, or a bus route). The Wikiuniverse could reinvent OSM's system for identifying places, or it could bite the bullet, lean more heavily on OSM's data, and make article references into explicit OSM references. Note that these references would not be OSM specific -- any map is going to have lat/lon and names of entities. It's just that the Wikipedia editor that helps make these links would use OSM lat/lons and names.
Well first of all, we should get away from the concept of 'article'. It's really clear now that most of this data will soon live in WikiData. Coordinate values have already been added, and it's only time until most of those existing values have been moved into WikiData and there is the OSM relation ID property to link from WikiData to OSM. For entities/concepts WikiData is the only thing that will be relevant real soon. And a bot can easily detect when those break. So what you want in this regard is already in process.
> Then, once Wikipedia articles can make reference to OSM objects, and you have a OSM-derived Wikimedia-hosted set of map tiles, then including a dynamic map in an article is simply a matter of a single command. And an article which is a collection of articles can make a map with references to those articles, again, with a single command.
This is thinking way too simple. Would it be nice to be able to do this ? Sure, but we already have dynamic maps. WikiMiniAtlas, the german OSM map. Those even have area highlights these days. Can they be better ? sure, is that something difficult, is it really needed ? No not really x2. Wikipedians are much more focused on making static maps usually. Or rather, they often want very specific types of maps, resulting in them using custom designed static maps. These custom maps have different base layer types for different types of articles (and sometimes for different cultures cross wiki), and very simple highlights in them (less is more). Or they want to mark the spot of an event (planecrash/hurricane path etc). If we do not recognize the target group, then the integration of the feature will fail.
Also, there are many problems with dynamic maps in articles (print, mobile, loadtime, fallback for users without JS). Can we do many cool things with maps ? sure. but where is the most valuable place to start ? That is a much better question I think.
Personally, I think the power is in annotation. The success of FA, Commons, WikiData and OSM have shown that our users love to not just 'collect' data, but to do the curation, annotation and restoration of this data.
Doing annotation using a simple OSM renderer as our starting point could be step 1. We need support for 'static' image maps to generate the buy in of people to start using this feature (step 2). With enough buy in, we can start going for the long haul, which is to build a very complex map renderer with a lot of different baselayer configurations, that might help us at some time achieve to phase out the static maps. But saying we need 'dynamic maps' is way too narrow and technical view.
The other thing we could build, would be the 'foursquare' microcontributions to our mapping data (can you pinpoint this location on this OSM map, there are five locations in this area, which one best represents this article) and then with enough confirmed information set/add/correct/suggest the OSM value in wikidata again. Things like that (gamification). I think that is where we have a lot of potential.
DJ
> And .... here's the money shot: your location gets shown on the map.
>
> BTW, Special:Nearby is broken. Android phone, Chrome Browser, GPS on and locked (Ingress is happy), "Quiet out here ... there weren't any pages found nearby." Yet I could throw a stone and hit the location of a page AND my Google Glass app is happy to report that a page is very close to me.
>
>
> On Fri, Mar 7, 2014 at 4:55 PM, Arthur Richards <arichards(a)wikimedia.org> wrote:
> Somehow wikitech-l got dropped form the recipient list of this thread; I know some of the OSM folks are subscribed. Anyway, re-added wikitech-l to this thread.
>
>
> On Fri, Mar 7, 2014 at 1:53 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> Sounds like a good idea. If there is no objections to my potentially crazy idea I will drop them a note on their mailing list...
>
> On 7 Mar 2014 13:27, "Arthur Richards" <arichards(a)wikimedia.org> wrote:
> Dunno if any of the OSM-y folks are planning to attend but I bet this would be up their alley. At the very least, it would probably be good to get their input on a project like this.
>
>
> On Fri, Mar 7, 2014 at 11:44 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> Dan awesome! Glad there is some interest - this should be a lot of fun! :-)
>
> On Wed, Mar 5, 2014 at 1:20 PM, Quim Gil <qgil(a)wikimedia.org> wrote:
> > fyi
> >
> >
> > -------- Original Message --------
> > Subject: [WikimediaMobile] Zurich Hackathon: Creating a map namespace
> > Date: Wed, 5 Mar 2014 12:54:52 -0800
> > From: Jon Robson <jdlrobson(a)gmail.com>
> > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>, mobile-l
> > <mobile-l(a)lists.wikimedia.org>
> >
> > This may be extremely ambitious, but I'm keen to kick off development
> > around the creation of a map namespace during the Zurich hackathon.
> >
> > The goal would be to setup an editable map namespace that could be
> > used for a variety of things, one of which would be adding a map view
> > to the Special:Nearby page provided via the mobile site. The goal is a
> > proof of concept not necessarily anything production ready (but that
> > would be great if we could get to that point!)
> >
> > Please let me know if you would also be interested on hacking such a
> > thing -
> > https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Geo_Namespace
> > - or if doing so would be a terrible idea (but if you have to go down
> > that route please provide constructive reasoning on what would be a
> > less terrible idea)
> >
> > Excited to hack on cool things in Zurich!
> >
> > _______________________________________________
> > Mobile-l mailing list
> > Mobile-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >
> >
> >
>
>
>
> --
> Jon Robson
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
>
> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
>
>
>
> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l