Although there might be links that do not have strong connections, if the
articles are written according to Wikipedia guidelines there should be a
minimal amount of such links (distractions and noise).
Every article consists of words and semantic structures. If we could
partition all the articles and analyse the occurrence of these structures
statistically we could see a different distribution for every article. If we
were proceeding further analysing these distributions, we could notice that
there are different types of these distributions and that they can be
categorised according to what they have in common. Let us pick up some
articles that represent categories,
http://en.wikipedia.org/wiki/Mathematicsbeing one of them. Then the
system would assign to each article a
probability or closeness to a certain category. So for example
http://en.wikipedia.org/wiki/Isac_Newton could have 15% Physics, 13%
Mathematics, 11% Famous People...
There could be numerous methods applied for the analysis - Bayesian
probabilities, PageRank and so on or their combinations.
Percentages are highly illustrative, relevance can be expressed with more
than one dimension as some combination of vectors or functions dependent on
some factors (time, location, depth of information span...).
Possible applications:
"See also" suggestions
Search results
Experimental semantic navigation
Analysis of scientific papers
Hello members,
I am Ashish Mittal, a pre-final year BE student of Computer Engineering from
Sardar Patel College of Engineering, India. I intend and am very keen to
take part in GSoC 2011 with MediaWiki as my mentoring organization this
year.
I am new to this list and to this organization and I wish to contribute here
as a developer.
I have already participated in GSoC 2010 under Sakai Foundation where I
created a subsystem ‘Event Explorer’ [0] for them. I have experience with
the mentioned required tools and technologies like Eclipse, Maven, Ant, Git,
SVN, MySQL, Struts, Grails, JSP, Servlet, HTML, CSS, Javascript/JQuery,
AJAX, JUnit and Mockito. I am good with UI interfacing and web 2.0 tools.
I got a local copy of MediaWiki and have installed it. I want to start
getting to grip with the architecture of MediaWiki.
I saw that MediaWiki has already started preparing for SoC 2011 [1]. I have
been through some documentations and this year’s project ideas. I am
primarily interested in *MediaWiki core* [2]. If you could plase give me
some important and relevant pointers which would help me understand the
project more, it would be very appreciated.
Also I wanted to know if there are some tasks which I could work on prior to
timeline so as to get a better understanding of the architecture and code
base. So if you could please give me some information on the above, it will
be very helpful to me. Thanks in advance.
[0] -
https://confluence.sakaiproject.org/display/KERNDOC/KERN-717+Event+Explorer
[1] - http://www.mediawiki.org/wiki/Summer_of_Code_2011
[2] - http://www.mediawiki.org/wiki/Summer_of_Code_2011#MediaWiki_core
Regards,
Ashish
--
Ashish Mittal
Student at University of Mumbai
Yahoo: av_mittal(a)ymail.com
Gtalk: ashishmittal.mail(a)gmail.com
Phone: +919930820950
In the next few weeks, I'd like to get Peter Potrowl's Summer of Code
project for InterWiki Transclusion (fixes Bug 9890
https://bugzilla.wikimedia.org/9890) reviewed and merged from his branch
into the trunk.
I've already asked Roan to help with merging this code, but Peter
pointed out that some of his revisions have been marked “deferred” in
Code Review. So, until Roan has time to help with this merge, I'd like
to get as much of this “deferred” code reviewed as possible.
Link to revisions marked “deferred”: http://hexm.de/0y
Mark
Hi, Sumana Harihareswara here, interim volunteer development
coordinator. Thanks for the introduction, Rob.
Nicole Ebber (Wikimedia DE -- thanks, Germany chapter!) and I are
organizing the Berlin developer Meeting in mid- or late May. We have
two strong candidates for the dates: either May 20-22, 2011 or May
13-15, 2011. Please indicate your preference as soon as you can on the
straw poll:
http://www.mediawiki.org/wiki/Berlin_Hackathon_2011#Straw_Poll
so Nicole can get the venue secured by early next week.
Also, it would be great for us to plan ahead for the sprints and mark
bugs for the bugbash. Please add possible bugs to the bug list
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Berlin_Hackathon_2011…
and consider what would be the best use of the concentrated developer
time in Berlin. While we have all this power in one place, let's hash
out a couple of issues and come to clear decisions. A few ideas from
the wiki page:
* New parser design
* Expansion of the Virtualization Framework
* toolserver's purpose and services, since we'll be in Berlin
but we should probably just focus on two, since we only have 2-3 days.
Best,
Sumana Harihareswara
Hi,
The February report of what was accomplished by the Wikimedia
engineering team is now available:
http://techblog.wikimedia.org/2011/03/wikimedia-engineering-february-report/
As far as I know, we haven't advertised these reports on this list in
the past.
I'd like to ask the list if you would prefer:
* to keep the status quo: you're content with the RSS feeds from the
blog and there's no need to post here;
* posting a link here is a good practice that you'd like us to continue;
* posting a link here is good, but you'd also like to get the content of
the report in the e-mail;
* something else?
Thanks,
--
Guillaume Paumier
Would it be useful to make a program that would create topic relations for
each wikipedia article based on the links and the distribution of semantic
structures?
I've re-added wikitech-l to the header since it was originally
addressed to both and your question
and my answer will update them at the same time.
And since it's now mostly tech-oriented feedback from them would be
nice as well.
A general note: If you're filing a new bug or feature request [0], be
sure to check open tickets [1] first ;-)
Right now the purpose / features of the plugin are:
* Easy searching of images on commons with autosuggested subjects
* Click-and-pick from the results to insert it in the page or post. A
WordPress shortcode is inserted
into the post ([photocommons file="Example.jpg" with="200"
align="right"]) which will be made
into a linked thumbnail with hover tooltip when parsed
* No need to maintain your posts if a file is moved on Commons,
redirects work finen (since there are
no paths or <img>-tags hardcoded
* No need to download/upload locally
* Promote Wikimedia Commons as an easy-to-use source to add images to
your blog or website and
avoid people from googling for images and uploading or hotlinking
random copyvios.
On March 4 2011, Teofilo wrote:
> 1) I have never used wordpress. What do I need to try wordpress and
> your tool as a beginner easily for the first time ?
> 2) How does your tool attribute photographers ? Can you provide a
> screenshot showing attribution ? Is the attribution printed on paper
> when the user prints the resulting page ?
> 3) Are you using http://wiki.creativecommons.org/RDFa ? If relevant,
> see my remarks at
> http://commons.wikimedia.org/wiki/MediaWiki_talk:Stockphoto.js#.22Use_this_…
1)
Like for MediaWiki, you need a simple local AMP environment (eg.
Apache, MySQL, PHP. So
install something like LAMP or XAMPP, or get FTP access to an existing
server with this).
Then these 4 steps:
* Install WordPress from the control panel of your webhost (if you
have one) or download it from
http://wordpress.org/, upload files, browse to them, follow
instructions on-screen
* Right now it's a development plugin, meaning not a plug-and-play for
the general public yet,
but for commos users and developers to see how it works and how it
could be made better. To
install the PhotoCommons plugin, check out most recent version from
SVN [2] or download zip[3]
* Follow install instructions (unzip, upload to /wp-content/plugins/wp-
content, browse to your
wp-admin -> Manage Plugins -> Click Activate)
* Create or edit a new page or post on the wordpress site, next to the
buttons to upload files locally
to your blog there now is a Commons icon above the editor. Click it
and have fun!
* There's no step 5.
2) Since it is impossible right now to reliably extract such
information we have choosen not to attempt
to regex, hack, uglify our way out of it one way or another. We are
waiting for the License
integration project to finish at which point we will be able to
dynamically extract this information
from the API in a snap and cache it and display attribution and
license under the thumbnail. For now
we are taking the same approach as the Wikimedia wikis do (slightly
better actually [4]), linking the
thumnail directly to the Commons file page and the title of the image
as tooltip when hovering the
thumbnail.
3) We are not, see 2). I'm totally convinced this should be done, and
we will as soon as licenses are
integrated this will be done.
--
Krinkle
[0] https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia%20Tools&prod…
[1] https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&component=…
[2]
* http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/wp-photocommons/
* http://www.mediawiki.org/wiki/SVN#Check_out
* $ cd mywordpress/wp-content/plugins
* $ svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/wp-photocommons
[3] http://files.wmnederland.nl/downloads/latest.zip
[4] Slightly better in that Wikimedia wikis link to the local cached/
transclusion instead of Commons directly.
It seems that someone's added a checkbox "Log me in globally" on
CentralAuth's modified Special:Userlogin. This is kind of not great in that
it clogs up the user interface with something that should always 100% of the
time be on, and should never be optional.
The feature request:
https://bugzilla.wikimedia.org/show_bug.cgi?id=20852
The commit:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/75041
If there's no strong objection, I'd like to revert it. If there really is
some very specific need for non-global logins (wtf?!) this should be
something that individual people who really need it can *get to* with their
secret wizard knowledge but not inflict on everyone else. ;)
-- brion
Hey,
(This is take 2 on this subject, as the last thread derailed into parser
internals discussions which have rather little to do with the Validator
extension. I also added some dev docs [1] which are likely to provide a
better picture of the extensions function.)
Over the past year I've been working on an extension to facilitate parameter
handling in MediaWiki, with a focus on parser hooks. It's titled
Validator[0], which currently is a bit misleading since it enables a
lot more then
simple validation. As the only thing this extension does is facilitate
parameter handling in other extensions, I think it makes sense to include it
into core, or at least in the default MediaWiki distribution. To be clear,
the subject of this request is only the parameter handling code of the
Validator extension. It also contains parser hooks for error handling and
automatic documentation generation, but I'm not proposing to put these into
core (they can easily be split off).
I created this extension out of frustration as an extension developer that
to create a parser hook, you need to do the same plumbing over and over
again, and have to write a whole mess of parsing and validation code that is
similar for almost every parser hook. Of course this is doable, but it's
error prone, causes small differences in how exactly parameters are handled
in different parser hooks (not very nice for the end users), and is hard to
maintain. If you have done this a few times, it becomes rather obvious that
a more generic framework to handle parameters would be a big win. You want
to describe a parameter, not all the details of how it should be handled.
Using Validator is somewhat similar to how API classes and their
getParameters methods work, but more powerful and extensible. I just wrote
up some documentation on how to create your own implementation using
Validator here [1]. If anything is unclear, please let me know.
Putting this functionality in core would be a big help to everyone writing
new parameter handling code, and would enable cleaning up existing
implementations where this is desired. As this functionality does not
replace anything in core, putting it in would not disrupt anything. I'm
willing to do the little work required to merge Validator into core.
I'd very much appreciate if some people gave useful feedback on the
extension in relation to its main functionality, parameter handling, and if
this makes sense to put into core or not. If you want to discuss anything
parser related, please start your own thread :)
[0] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:
Validator
[1]
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:Validator#I…
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Just a head's up that the old problems with Proxy Errors and lost
login status on edits are happening again after no complaints for a
couple of years. Also, at least last weekend, I noticed that cache
flushing didn't happen for some of the pages I edited.
https://bugzilla.wikimedia.org/show_bug.cgi?id=19587