cniehaus at gmx.de
Sun Jun 26 12:26:48 CEST 2005
I am sitting in the train back from the LinuxTag and have four hours to kill.
When I arrived Danimo suprised me by telling me that the dpa (biggest german
news agency) has been informed about the wikipedia and KDE-cooperation. Well,
in german magazines Kalzium and KStars have been named as the prime examples
why this is a good thing :)
In the last couple of days I've been talking to elian from the wikipedia (she
is an official leader of the wikipedia and represented it on the LinuxTag)
and of course Daniel Molkentin, Tobias Koenig and others. What is all this
about? kdelibs will get classes and methods which in effect allow us
application-developers to very easily get content from the wikipedia.
What do we need from kdelibs API-wise? Tobias, Elian and I had a discussion
and pretty much agreed on this API:
* validate if an article exists
-- bool articleExists( const QString& articlename )
* return an article (wiketext, xml or html) which I request
* @param articlename the name of the article
* @param type defines if this returned string is in XML,
Wikitext or html
-- QString getArticle( const QString& articlename, DocumentType type )
* return several articles (wikitext, xml or html) which I request by
-- QStringList getArticles( QStringList articles, DocumentType type )
* return the users who modified an article. This is needed because the
GNU-FDL requires that you name all contributors of an article. I suggest
that we don't display them in a text but have "Author"-Buttons.
-- QString articleAuthors( const QString& articlename )
* return the full-size version of an image. In an article there are usually
resized pics, sometimes even in stamp-size. There has to be a
mechanismn to retrieve the fullsized version and possible if there are
diffrent versions. For example: A wiki-guy uploaded a picture to
wikicommons. That pic is named foo.jpg. In the chinese wikipedia there
is no local foo.jpg. So a chinese user would get the picture from
wikicommons. In the german wikipedia there is a foo.jpg. This will
have a higher priority (local before commons) so that a german user
will get a diffrent picture. That is the wikipedia-behaviour and it
makes sense. But we have to keep it in mind.
* The content our applications will be displaying needs a fallback version
(offline). This is because at any time it is possible that a article
is vandalized. Usually these changes are reverted within a few minutes our
hours but still this is a risk. There there should be a setting to
fall back to a offlineversion which has been checked by the developer(s).
Furthermore this will make it possible to have the full functionaliy
when you are offline, behind a strict firewall. A last plus is that this
will reduce the traffic of both the wikipedia and the users connection.
** The size of that offline version might become a problem. With pictures
it might become pretty big soon
** Who will check eg the chinese version? The chinese translator? The
*** Elian proposed that we (KDE) will create wikipedia.kde.org. On
this page the authors will list the articles they are using. In my case I
would make a list (eg in a simple xml are csv-file). I script will
create a html-page out of this file (I volunteer for writing this
script in Ruby). On this page we will mention on which date we will
grep the articles from the wikipedias (the chinese, german, english
and so on). The wikipedia-guys will take care that on that date
there are only good articles.
Another point is that this will also show which articles have not yet
been written in the different languages. Elian said that this
situation will pretty quickly make people write or translate the
I guess it would be best to have those releases downloadable. It would
probably much to much data (eg 50*2mb == 100mb additional)
** We will update those offline-databases with every release of
KDE, perhaps when the strings are frozen I guess. This won't increase
the workload of the kde-translators as all translations will be
provided by the wikipedia.
** What happens if an article is not found? The answer is pretty
simple: kde has already a priority-list in (I think) KLocale.
A user can for example define fr, nl, de as his list. In this case,
if article is not found in the french wikipedia it will be
taken from the dutch wikipedia. If it is not there and also not
in the german wikipedia it will be taken from the englisch
wikipedia. And it will definetly be there becuase the developers
will make sure that they only use articles which have an entry in
the english wikipedia.
** If we developers want to have a specific article written but
can't do it ourselfs for some reason we will but a request on
the wikipedia.kde.org-page. Chances are pretty good that it will
be written within a few days as the wikipedia-folks will keep
a close eye on that page.
** I for one will furthermore add those articles to my
Wikipedia-userpage in the german and english wikipedia where I
will also add them to my personal watchlist so that I can
easily track all changes.
** There will also be cooperation with the chemical team of the
german and english wikipedia so that the articles I need will
quickly gain quality and quantity.
** Common glossary interface / dialog **
I think that the glossary which is currently used in Kalzium would also fit
very well in KStars, but probably also in KIG and other apps. In the future
it will be pretty simple to get the content from the wikipedia. Therefore we
should move the glossary in a little more abstract from Kalzium into
It should be like in KDialogBase: inherit from EduGlossary, add some widgets
here and there and you are pretty much done. All the data-stuff can probably
stay abstract as we would use the same fileformat.
I hope you have many comments. Please tell me what you think what is good in
the above and what is bad but of course also what is missing. When we agreed
on things I will inform the wikipedia and some KDE-guys like Danimo about it.
But I think we should agree on what we need and what we do not need before
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-edu/attachments/20050626/3484bc4c/attachment.pgp
More information about the kde-edu