Today Jimmy Wales, chairman of the Wikimedia Foundation, announced the beginning of a cooperation between Wikimedia and the KDE project at LinuxTag in Karlsruhe, Germany. As the first applications, like the media player amaroK, start to integrate Wikipedia content the idea is to create a webservice API to access the information from Wikimedia projects such as Wikipedia or Wiktionary. There are also plans for a KDE API.
The API would allow KDE applications to easily embed Wikimedia content, data could even be fetched from a local database depending on your online/offline status. First progress can be seen in Knowledge, a Qt 4 based offline reader for Wikipedia.
Jimmy was also searching for people who want to help with the design of this API, so if you want a good API for your application join the efforts!
Comments
This will be really great for the "AstroInfo" articles in KStars. These are short, hyperlinked articles about astronomical concepts. They are currently in the KStars handbook, but I've been thinking for a while I'd like to break them into a separate reader and make it more tightly integrated with the rest of the program.
Some of the AstroInfo articles have already migrated into Wikipedia.
Seems like a good opportunity for two great projects (KDE and Wikimedia) to help each other out.
Hi Jason :)
Of course KStars is one of the most obvious applications where Wikipedia-Integration would make sense. Actually it was even one of the first ones mentioned when we started to think of a stronger KDE-Wikipedia cooperation. For KDE-Edu in general it's certainly a huge opportunity because we could get some translated high-quality part of the "documentation" integrated that way.
Now we just need some generic mechanism which makes i18ned offline-reading easily possible with "preshrinked"/optional contents for the KDE-EDU packages.
Danimo is working on this already.
yes, but are there free offline package of Wikipedia available? Last time I talked to danimo, that was the issue. Is it solved?
If Wikipedia is available on CD/DVD (which it is) then I assume that offline packages should be possible (if only as cache).
Not yet -- at least not in a suitable form for distributors and KDE.
Ideally we would have a tool which would make it possible for packagers to specify the desired category(/ies), certain core-keywords, the language(s) and the limit for the amount of data. The tool would then create an offline package which would be tailored down to the packagers / distributors needs.
Of course creating such a tool is certainly much less work for KDE than to recreate glossars for each educational application and translate and update them on our own ...
i can only agree - i hope the kstars developer(s) can join here!
The Kalzium-devs already joined :)
that's wonderfull news! cool to see all this cooperation! that gives one confidence the path chosen is right...
If you wish to follow this in the future there's an open bug for external APIs here: vhttp://bugzilla.wikimedia.org/show_bug.cgi?id=208
A great feature would be a point in kontextmenu of the kicker watch that is called "Show this day in history" (or something simmilar). So that konqueror is started and shows the wikipedia entry for the current date in history.
Example: It's the 24.06.2005 (I'm sorry for writing the date this way, but I'm Austrian and don't really know the American or English way :)) Klick on the menu entry and konqueror shows up with the URL: http://de.wikipedia.org/wiki/24._Juni
Patrick
> (I'm sorry for writing the date this way, but I'm Austrian
> and don't really know the American or English way :))
Yeah, I'm Austrian too, and already faced this a little bit. I think the most important non-German date formats are the international one (YYYY-MM-DD, like in SQL for example) and some English or American one (don't ask me which, but it's MM/DD/YY). I'd use the international one if I need to write dates.
And for your idea - not bad, I like it :)
I believe American is MM/DD/YYYY and English (also Australian) is DD/MM/YYYY.
L.
I thought the German was DD/MM/YYYY too, as a German friend told me how he was unable to buy beer in the USA as they expected his passport to have his date in the MM/DD/YYYY format.
He ended up taking a driving test to get some American ID.
The whole of Europe is DD/MM/YYYY. I think everywhere except the US is.
To be picky: not exactly!
For example, Germany uses dots as separator: DD.MM.YYYY
And the European Norm is in the international one: YYYY-MM-DD
(It is even the national norm now in many (old) E.U. countries, even if not used commonly.)
Have a nice day!
All of northern Europe uses (YY)YY-MM-DD.
Would be nice for the Kontact summary page also.
"en:SOAP/en:WSDL is probably the best choice since it can deliver semantics (as opposed to en:XML-RPC) and is an accepted industry standard also used by e.g. google"
Please consider REST style web services, which, IMHO, are much easier to use and more powerful. Read this article for quick introduction to REST: http://www.xfront.com/REST-Web-Services.html
For more info, there is a wiki: http://rest.blueoxen.net/
REST?? IMHO AJAX is teh cool & more appropriate.
http://www.sagal.com/ajax/
I think you've got the wrong idea.
AJAX is at it's heart a presentation technology, not a web service technology. An AJAX application may connect to a web service to retrieve data, but is not the enabling technology for the web service itself.
The main web service technologies are:
- SOAP (venerable, complicated, powerful, standard)
- XML-RPC (much simpler, but missing some power)
- REST (believed by many to be the best of both worlds)
L.
Unfortunately for you, I'm afraid I can't express my disdain about these silly acronyms you so favor any better than the link I provided in the previous post.
If I understood correctly, REST isn't really a technology, it's more like a design approach to web APIs. While SOAP tries to solve everything inside SOAP itself, REST means you rely on existing mechanisms (URLs, HTTP) as much as possible.
I wouldn't be surprised if KDE will choose REST eventually, just like DCOP was developed on top of existing mechanisms (ICE) when CORBA turned out to be too complicated.
> If I understood correctly, REST isn't really a technology
Absolutely correct. Rest is what you do when tired you are. Soap is what you use when bath you take.
Yoda Talk is what you do, when you watch too much Starwars.
Here is some information on REST: http://www.xml.com/pub/a/2004/12/01/restful-web.html
Rich.
AJAX is not a technology *at all* - it is a buzzword co-opted by Adaptive path to describe a technique for asynchronous data retrieval by using the XMLHttpRequest pbject, that they like to think they invented.
Too bad web developers (such as myself) had been doing this for years earlier.
AJAX is not a protocol - the protocol is HTTP. It is not a data format - the data format is XML and/or JSON. It is just a buzzword.
I agree completely. SOAP is hideous compared with REST (which is actually just a buzzword; REST simply means "use HTTP properly").
"SOAP is probably the best choice" sounds like somebody who isn't very familiar with web services thought that the only options were SOAP and XML-RPC, and took five minutes reading FAQs to decide that he preferred SOAP. It does not sound like an informed, considered opinion and hopefully it will change.
Making all of the GFDL text corpus processable via REST would be a very very very good thing indeed - please see this slashdot.org comment: http://slashdot.org/comments.pl?sid=153801&cid=12901846
Hope the translation issue also gets adressed. KDE's translation infrastructure is getting outdated.
Outdated? What's your issue with it?
The translation project does not scale anymore. There is a huge translation lag, contributing is not as easy as it could be. And the translation infrastructure almost came to a standstill.
Just look at
http://i18n.kde.org/stats/gui/stable/index.php
or even worse
http://i18n.kde.org/stats/doc/stable/index.php
Contributing is still as easy as it was 3 years ago, and a lot easier then it was 5 years ago. (5 years ago, you had to use an editor, like kwrite or nedit, nowadays you can use special po-editors, webbased interfaces, translation memories, etc. etc...)
The difference between the years is that the amount of strings that need to be translated is a lot larger.
Statistics don't tell the whole story about the status of a translation team. Some teams decide not to translate all available software in cvs, but to maintain only thos apps that make sense to them. Statisticly those teams came to a standstil, while in reality they are continuing improving their current translations..
Also, looking in 'stable' does not give you the correct picture. For example, the Dutch team is translating the docs in 'trunk', not in 'stable'. And now that extragear can use branches, third party applications will probably appear in the 'stable' stats of i18n.kde.org. Not every team is translating third party apps, so the stats will go down...
Besides, whatever infrastructure we will use, translating documentation and applications will always mean that you have to translate the English strings, and that is a very time consuming task...
What the translation teams need is people who are willing to spent some of their precious time translating the gui and docs to their language..
Rinse
What the wiki way showed us was: lower entrance barriers and the project will lift up. Wikipedia reached what the closed open contribution project Nupedia failed to reach. Translation is an easy task but it is not made easy.
- you have to contact the project and get involved
- you have to know what po and pot files are
- you have to get the right files.
- you need knowledge of KDE internals, SVN
Webbased tools for translations are of course a great contribution but currently third party.
There are today much more KDE users than 3 years ago. The translation infrastructure does not scale. It does not attract contributors. Community plattforms such as KDe-look or KDE-apps were also a great example what can be achieved whwn you lower entrance barriers.
"The translation infrastructure does not scale."
While everything else you wrote is fine and dandy (and mostly bogus in KDE's case unless you are the first translator of your mother language) what's your proof for the above statement?
It does not scale means: A lot of new apps are added but the "low involvement" task translation does not adapt in a fast way. Even major KDE languages such as German are not 100% done in the stable branch. Note that there are many KDe users in Germany.
I know that some review is needed. But contributing is currently not an average joe task. Translations have still a serious lack. While programming and development in general becomes easiert the translation infrastructure was frozen in say 2002, regarded as good enough. i don't think it is.
Looking at the German stats, Except for kio_svn.po and some strings in spy.po their translation of the official KDE-modules is completed.
kio_svn.po was added after the release of kde 3.4.1 (afaik), so it's no wonder that one is untranslated. The german team has until july 17 to translate it :)
Looking at the stats of the german koffice, You will notice that krita, kplato and kivio are unfinished.
Both krita and kivio contain a lot of strings that need more than average knowledge of the subject to translate.
In those cases, the fact that they are po-files is not the barrier, but being familiar with the typ of application is.
I don't see how a wiki or other webbased solution can solve that.
One of the major issues that a wiki does not solve either is the quality of the translation in order of consistency with other parts of KDE. One can translate the hundreds of different colors in krita, or the hundreds of different stencils kivio by sucking them out of you thumb, but that would end up with a shamefull translation rather then a usefull translation.
Looking back at the Dutch translation of Krita, most of the color strings are left untranslated. But you won't see that in the stats, because we copied/pasted the English phrase to the translation. If the German team also decides not to translate the named colors, but does not copy them to the translation fields, then their stats would put them behind the Dutch team, while in real life they are not. (like i said earlier, stats don't tell the whole story)
Forget about the stats. It is about the fact that in the current translation model translation is not the easy taks it is supposed to be.
And documentation is really worse than GUI. The team does not scale. The question is: how long will it last to translate 100%, is the change and new string expansion faster than what a translation team contributes.
We don't want a translation lag.
I understand pretty well that translation is not that easy, that it requires high skills.
It is more a recruitment issue. Open models are always superiour.
> It is about the fact that in the current translation model translation is not the easy taks it is supposed to be.
But why isn't it?
You don't come up with any reason of why the current model fails...
>I understand pretty well that translation is not that easy, that it requires high skills.
>It is more a recruitment issue
You won't reach more users with high skills by lowering the barier to join a team.
It is the opposite, to ensure that you get volunteers that are capable of doing the job right, you need to have some kind of tresshold.
What the wiki way showed us was: lower entrance barriers and the project will lift up.
Looking at wikipedia.org, most Dutch translations are incomplete or outdated.
With wiki, it is true that the initial translation is easier, because of low entrance etc, but keeping the files up to date compared to their English equivalents is much more a pain than keeping po-files up to date.
you have to contact the project and get involved
Not necessary, but in general a good idea.
you have to know what po and pot files are
You only need to know that your working with po-files, just like you need to know that you are working with doc-files when writing a letter in MS Word..
you have to get the right files.
which are available from i18n.kde.org, just click on the right file to download it.
Or use a webbased system like pootle to organise the translation project, you can't translate the wrong file with pootle :)
you need knowledge of KDE internals, SVN
It's alway nice to know what you are translating, so knowledge of kde is indeed necessary.
But SVN knowledge?
Why?
Webbased tools for translations are of course a great contribution but currently third party.
Not true, there are several GPL-based versions, like pootle and another one of which i forgot the name of (the nameless one is part of the kde project)
Also, Wiki is third party..
There are today much more KDE users than 3 years ago. The translation infrastructure does not scale. It does not attract contributors.
That is not true.
Looking at the Dutch project, while a few years ago translating was allmost a one man job, now about 10 people are translating the desktop, and especially the documentation has never been this far translated in the past (currently 70%)
Community platforms such as KDE-look or KDE-APS were also a great example what can be achieved when you lower entrance barriers.
You can't compare kde-look and kde-apps with translating software.
Things like wiki sound nice, but it is not in any way sufficient for translating software or docbookbased helpfiles.
First, a wiki does not have a translation memory. Without a translating memory, you need far more translators to do the job.
For example, the documentation of digikam contains about 28458 words (tags not included). Translating that amount of words would take several months. But since most of the chapters of the digikam documentation are using the same layout, about 60% of the docs can be automaticly translated with a tool called kbabel. Besides errorprone copy&paste, I can't think of a way with wiki that a translator can automaticly translate files based on earlier work from other files.
Another benefit of using po-files for documentation translation is that you don't have to deal with most of the tags and elements found in docbook sources of the kde help files. And the tags that are left over can be filled in with a single keystroke in kbabel.
That is also something I don't expect to do using a wiki-based translation.
Third, small changes in the original docbook-files are easy to find without the use of a diff-application.
Just checkout the sections in the po-files that are marked as 'fuzzy'
New and changed English strings are automaticly integrated in the po-files, and the translator only has to startup a po-editor like kbabel, or surf on the net to pootle, and move from fuzzy/untranslated to fuzzy/untranslated with just a single mouseclick or keystroke.
And last but not least, most translation projects resides in countries that don't have the luxury of flat-fee broad band internet. Using a wiki as translation tool (or any other kind of webbased solution) would mean that they need to use a dialup-connection with the internet while translating, which would make translating quite an expensive job to do...
"With wiki, it is true that the initial translation is easier, because of low entrance etc, but keeping the files up to date compared to their English equivalents is much more a pain than keeping po-files up to date."
This is a problem of diffs. English as a primary documentation source, when the english version is changed, the translation has to adapt.
Wikipedia articles are usually not translations, so this is different. More articles about the same topic.
With KDE documentation it is 99% direct translation with perhaps other wording. So a change in the english original triggers a possible change need in the derived document.
> Things like wiki sound nice, but it is not in any way sufficient for translating software or docbookbased helpfiles.
It is not about using a wiki. It is about doing it the wiki way. Linux Professional Institute used a succesful system to get translations of articles on their website.
t7e http://www.lpi.org/en/projects.html
>Wikipedia articles are usually not translations, so this is different. More articles about the same topic.
So you agree that a 'wiki' way of translating documents is not the option.
>It is not about using a wiki. It is about doing it the wiki way. Linux Professional Institute used a succesful system to get translations of articles on their website.
But this is not about websites or other 'instant publishing' mechanismen, we are talking about the translations applications and documents that have a release schedule, deadline, etc.
If your translation is finished, one day after the freeze, your translation is not included and won't be until the next release.
No wiki-kind of translation mechanism can avoid that.
wrong stats link. This is the important one:
http://i18n.kde.org/stats/gui/stable/essential.php
Doesn't look too bad to me.
> The translation project does not scale anymore.
in what ways? can you offer some examples?
> There is a huge translation lag,
define "huge" and is this due to available person hours, # of strings needing to be translated, of translation patches being triaged? you're being a bit vauge here =)
> contributing is not as easy as it could be.
what would you suggest for improvements?
> And the translation infrastructure almost came to a standstill.
what infrastructure was this, and when did it "almost come to a standstill" exactly?
I mean:
Do it the wiki way. Imagine I had twenty minutes left and want to translate a portion of a KDE doc. I do not want to subscribe to mailing list. I do not want to learn SVN or get to know po or pot files orr tools like kbabel.
Translation of your ideas on translation: You don't want to do a good job properly and in the proper application context.
KDE needs serious and dedicated translators not people with low standards.
The wikipedia way means recruiting high involvement people by low entrance barriers. The truth is that a core of 1000 supporters max writes most of the articles. it is alwways the 80-20 rule. But how do you get these people involved?
Translation is said to be a job for non-programmers but fact is it currently requires some skills, there are unecessary barriers.
Translating applications are NOT simply about changing strings to a new language, it is not that easy. And you also have to do testing and debugging of your translation, which imply actually running it with the translation. Spend some time reading the translation mailinglist and you would see.
But if you really want to use those twenty minutes of yours helping with translation of KDE, it's easier than with any wiki out there. You translate the documentation, it's the most neglected or lowest priority part of the translations too. As for the easy part, you only have to supply the text. The language maintainers will gladly help with markup, and integrating it into the correct place in svn. Since its' only text you can even write it directly in your e-mail client if you like, and send it to the appropriate maintainer.
At a wiki you can edit it on the fly. html editing is also easys but the wiki way means, you see an error and just correct it.
Hi can edit on the fly, that is true, but only when you are writing documentations.
Not when you create translations of documentations.
An initial translation in a wiki is quite easy, but keeping it up to date according to changes in the English version is not.
For example, if the English author changes 6 words in a document containing 25.000 words, in order to reflect GUI-changes in the next release of KDE, how is the translator supposed to find those changes in his translation?
If you look at wikipedia.org you will notice that most localised articles are not translations of the original English versions, most of the time they are rewrites that contain some, but not all, of the information that is available in the English version, most of the times complemented with information that is of interest to the audience of that language.
And again, most translated documents on wikipedia.org are outdated or contain less information then their English counterpart.
If wiki is so great for translating, why can't wikipedia (with a much larger audience then localised kde-versions) keep up the pace???
I don't mean document editing via a wiki which might be a good proposal.
I mean the principle of wiki: low entrance barrier for participation.
> And again, most translated documents on wikipedia.org are outdated or contain less information then their English counterpart.
German articles are usually independend from the English ones, not translations of their English counterparts.
> An initial translation in a wiki is quite easy, but keeping it up to date according to changes in the English version is not.
Diffs are your friend.