Last modified: 2014-09-24 13:41:09 UTC
I can't seem to find a pre-existing bug, but Wiktionary needs a usable API.
Currently Wiktionary relies on MediaWiki's api.php, but that was (largely) built for Wikipedia. A proper Wiktionary API would allow retrieving definitions in a particular language from a language version of Wiktionary. Probably a few other things as well. ;-)
This should be a tracking bug. But I don't know of any other issues to put here.
This idea has been suggested by Siebrand as a potential Google Summer of Code projects at http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Wiktionary_APIs
Does this make sense? Has there been any discussion in the Wiktionary community about specific API needs? I just want to know whether we would have a roughly defined project for a student. If the students should start by going to English Wiktionary and ask then this is not a feasible project proposal for GSOC 2013.
If the idea makes sense we would also need at least one mentor.
(In reply to comment #2)
> This idea has been suggested by Siebrand as a potential Google Summer of Code
> projects at
> Does this make sense? Has there been any discussion in the Wiktionary
> about specific API needs? I just want to know whether we would have a roughly
> defined project for a student. If the students should start by going to
> Wiktionary and ask then this is not a feasible project proposal for GSOC
> If the idea makes sense we would also need at least one mentor.
Note Ive previously tried to do this. Well part of the reason my attempt semi failed was that I was a newbie at the time I would like to state this is not the easiest problem to solve (esp. If you intend to keep wiktionary the same as it is currently without any explicit machine readable annotations)
Btw for reference my http://en.wikinews.org/w/index.php?title=User:Bawolff/sandbox/Wiktionary_query (don't view on mobile site)
Its not exactly an api, but does similar things to an api. Part of the reason it sucks so much were naive design choices that were horrid (younger me was stupid. If you read the code don't judge too hard). Anyhow as a result of my experiance with that, I wouldn't reccomend this as a gsoc project unless the student already had quite a bit of proper experiance with parsing.
Side note: the usual first approach to this is look at existing dictionary api standards. There are a large number of existing, mostly proprietary, systems currently in production using en.Wiktionary mapped to existing standards. There are almost no efforts doing so with other languages.
If someone would just implement RFC 2229, that would be awesome. https://tools.ietf.org/html/rfc2229
Alternatively, make the api calls as compatible as possible with that RFC.
A couple hours doodling for projects using wiktionary content, particularly going to DICT or WordNet, or code discussions on parsing wiktionary content (very popular whinge topic on stackoverflow):
(svn checkout http://wik2dict.googlecode.com/svn/trunk/ wik2dict-read-only)
http://inamidst.com/phenny/modules/wiktionary.py (ircbot module extracting data/metadata from wiktionary)
http://goldendict.org/forum/viewtopic.php?f=5&t=1205 (en.WT for GoldenDict)
http://www.aaaipress.org/Papers/AAAI/2008/AAAI08-137.pdf (Using Wiktionary for Computing Semantic Relatedness)
*** Bug 21450 has been marked as a duplicate of this bug. ***
To make this happen Wiktionary needs to store its data in a structured and machine readable format. We have proposals for how to make this happen at https://www.wikidata.org/wiki/Wikidata:Wiktionary/Development. Once that is done the API will be done as well.