[kde-edu]: LinuxTag::Wikepedia

[Carsten Niehaus]

Hello KDEEDU

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
  using QStringList
  -- 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
     wikipedia?
         *** 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
         articles.
 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 
libkdeedu...
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 
that.

Carsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-edu/attachments/20050626/3484bc4c/attachment.pgp