Work is currently underway regarding the integration of an upload tool to Wikimedia Commons as part of the KIPI plugins. See http://commons.wikimedia.org/wiki/User:Guillom/KIPI

See also bug 143978

*** Bug 265202 has been marked as a duplicate of this bug. ***

I work with Guilaume Paumier on this subject during KDE-Imaging coding sprint 2009. 

Some code have been done, to create a new plugin, but it's so far uncomplete. At least, you can use this code to continue, based on Facebook export tool.

Look code here :

http://websvn.kde.org/branches/work/~cgilles/wikimedia/

Gilles Caulier

Hello,

We had a look to your facebook code but there are no comments in the source code. We would know what classes we have to modify and what classes we have to re-use.
We also need some information about your facebook classes. 

IUP ISI Team

I CC Luka Renko who is author of FaceBook tool. He is the right guy to guide you in this tool classes.

Gilles Caulier

Hello,
We would like to know how works metadata in Digikam. Moreover, we want to extract and send them to Commons.Wikimedia.
Best regards,
The IUP ISI team.

What do you mean by Metadata ?

Rating? Tags? Exif/XMP properties ?

Gilles Caulier

The main metadata relevant for Wikimedia Commons are:
1. Image description (in multiple languages, if available)
2. Author's name
3. Copyright information
4. Date created
5. (optional) Geolocation
6. (optional) Tags, to match categories on Wikimedia Commons

This information can be stored in the digiKam database, or in the EXIF/IPTC/XMP metadata, whether the user has chosen to write metadata to the files or not.

The tool should extract this information from the database or the files, then include and format them appropriately to build the file description page on Wikimedia Commons.

Robin, I suggest you look at similar KIPI plugins (such as the facebook or flickr plugins) to see what classes & methods are used to access this information.

About code to extract digiKam DB information, look in digiKam kipi interface :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/kipiiface/kipiimageinfo.cpp#L125

In fact this metadata are named Attributes in this interface. Not all digiKam metadata are exported to plugin, but it's very easy to handle new one. The container in digiKam is Imageinfo :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/database/imageinfo.h

An example how to play with this attributes into a plugin :

https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/master/entry/picasawebexport/picasawebwindow.cpp#L446

Gilles Caulier

Guillaume,

As you have said me recently, Mediawiki plugin cannot be used in production now due to a wrong way to talk with mediawiki web service.

It work (just tested) but it use a non standard way... Right ?

This require some changes in source code (libmediawiki ?)

Can you give me a plan of fix to see if i can enable this tool in next kipi-plugins 2.0.0 ?

Thanks in advance

Gilles Caulier

(In reply to comment #10)
> 
> It work (just tested) but it use a non standard way... Right ?

Not exactly. The protocol used is fine. The main problem is with missing information.

When you upload to Wikimedia Commons, the following information is mandatory for each upload:
1. Description of the topic of the picture (what is it about?) (and ideally, the language in which the description is provided)
2. Author and license (copyright information)
3. Categories (i.e. classification)

Point 2. is the most important, and is implemented almost perfectly. No work is needed for now.

Point 1. is implemented half-way: The user is able to provide a description when they open the export window to Commons, but it's not practical when you're uploading multiple images. If you want to provide a different description for each image (which is usually the case), you need to upload them one by one, which kind of defeats the purpose of a mass uploader plugin.

So what is needed for point 1. is the ability to automatically pull the description from the digikam database or the file metadata. Digikam provides a very good interface to add descriptions to a picture, and in several languages (which is ideal for Wikimedia Commons). So we just need to pull that information and use it when we build the image description page for Commons. Although this is not a blocker, it doesn't really make sense to release without this feature imho.

The real blocker is point 3.: the plugin currently offers no way for the user to provide categories for the images they upload. If we release the tool as is and people start uploading their images without categories, they'll get a lot of hostile messages from the Commons community who'll have to clean up their uploads. The digikam / kipi people will get blamed because the plugin simply doesn't allow the users to add categories.

There are two ways to fix this issue.
* One way is to do something similar to what we have for the description: add a field in the window of the uploader, and apply the categories in that field to all the uploads. This solution suffers from the same flaws as explained for the descriptions: usually, the files you upload need different categories. Which leads me to the other solution...
* Use special tags as categories. The solution is not ideal but it's the best possible if we want to release the plugin soon (and I think it's good enough for now). Digikam has an awesome built-in tagging interface. Let the user use it to indicate the Commons categories they want for each picture. All you need to do is make these category-tags special in some way. For example, you (as developers) can decide that Commons categories will be the tags that have the "Category:" prefix. Or that they're the tags that have the "Wikimedia Commons categories" parent tag. In any case, the user can add these tags to their images (using the names of existing Commons categories that they'll find on Commons), and when they upload the files, you simply read the special tags assigned to each image. Done.

Also, each picture that is missing either a description, or an author, or a license, or at least one category shouldn't be uploaded. I realize this is a bit cumbersome, but it's the way things work for now on Commons. Maybe in a future evolution of the plugin, we can offer a better interface to explain this and encourage the user to provide the information.

Another point: the plugin is technically able to upload to any MediaWiki-powered site, but the interface doesn't provide a way to specify that wiki. I recommend to advertise the plugin as a "Wikimedia Commons export plugin" for now, and rename the appropriate files/folders. I completely agree that it'd be nice to provide a generic export plugin to any MediaWiki site, but for now we don't have that.

For the same reason, I recommend to remove the drop-down menu in the export window that lets the user choose between the test Wikipedia, the French Wikipedia and the English Wikipedia as target for the upload. Those were fine for testing, but for production use, we should only upload to Wikimedia Commons, not to any of the three wikis currently in the drop-down menu.

There are other things that should be improved, but the list above summarizes the most important items. For me, it was easier to list everything here, but feel free to break the list into several bugs if you find it more convenient. 

Last, here's a list of easy things to fix for which I can provide patches in the next few days:
* The description page that is generated has a few issues, mostly due to extra spaces.
* We should add a tracking category to know which images were upload with the kipi plugin.

If something is unclear in what I listed here, please let me know in the follow-up comments. I'll do my best to answer in a timely manner.

Guillaume (Hormière),

It sound possible to fix these issues reported by Guillame Paumier, before 2.0.0 final release planed arounf july ?

Gilles Caulier

To all wikimedia developers,

I don't receive any feedback since Guillaume Paumier comment #11

Kipiplugins and digiKam 2.0.0 final release are planed in few weeks.

- I must to know if i lets Mediawiki Export tool disabled for this release ? 
- Do you plan to work on it in a near future ? 

Best

Gilles Caulier

I did not planed to work in a near future on Mediawiki Export plugin, only on Libmediawiki if the library need some fix and improvement.

Best

Guillaume Hormière.

https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/master/annotate/mediawiki/wikimediajob.cpp#L140


In the buildwikitext function, what is the syntax for adding the list of categories before uploading to wiki?

Guillaume (Paumier),

Look #15, this question is for you...

Gilles Caulier

(In reply to comment #15)
> https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/master/annotate/mediawiki/wikimediajob.cpp#L140
> 
> 
> In the buildwikitext function, what is the syntax for adding the list of
> categories before uploading to wiki?

It would probably be something like:
text.append( "\n[[Category:Foobar]]");

Where Foobar is the name of the category, and everything in a loop to add all the categories

Created attachment 68795 [details]
Patch to clear the problem with mediwiki plugin

1) Removed the Description edit box and fetching description from kpimageinfo class.

2) Fetching the tags from kpimageinfo class and appending it in the buildwikitext function.

Guillame,

This patch go to the right way for you ? Please take a look.

Thanks in advance

Gilles Caulier

Created attachment 68817 [details]
Patch to clear the problem with mediwiki plugin

1) Description from kpimageinfo.h
2) Tags with "wikimedia" in them become the categories for wikimedia.

Guillaume,

I have attached a patch, please test it and confirm.

Guillaume,

Patch from Parthasarathy is enough to enable mediawiki kipi plugin for production ?

Gilles Caulier

(In reply to comment #21)
> Guillaume,
> 
> I have attached a patch, please test it and confirm.

Thank you! I'll do that shortly and follow up on this bug.

Created attachment 68983 [details]
Patch to clear the problem with mediwiki plugin + changed the urlentry type.

1) Categories for mediawiki upload.
2) Description from imageinfo
3) KurlCombobox for urlediting.

Created attachment 68986 [details]
Patch to clear the problem with mediwiki plugin + changed the urlentry type.

1) Description from imageinfo
2) Categories for mediawiki
3) Kurlcomborequester for entering url

Git commit 72f7fa88be6b4a742b1696ef930851428f534359 by Gilles Caulier.
Committed on 23/02/2012 at 16:19.
Pushed by cgilles into branch 'master'.

apply patch #68986 from Parthasarathy Gopavarapu + few improvement of code about gui layout and coding style.
wiki url history is saved/restored between sessions.
All points listed by Guillaume Paumier from comment #11 of bug #206842 are implemented.

M  +1    -2    CMakeLists.txt
M  +9    -8    mediawiki/wikimediajob.cpp
M  +9    -5    mediawiki/wikimediajob.h
M  +81   -64   mediawiki/wmwidget.cpp
M  +26   -22   mediawiki/wmwidget.h
M  +50   -30   mediawiki/wmwindow.cpp
M  +21   -15   mediawiki/wmwindow.h

http://commits.kde.org/kipi-plugins/72f7fa88be6b4a742b1696ef930851428f534359

To Guillame (Paumier),

With my last commit, plugin is fixed following your recommendations, listed into #11.

Thanks to PARTHASARATHY to contribute.

Plugin is now enabled by default, and will be available for next 2.6.0-beta2 release, planed into 2 weeks.

Please test current implementation to see if nothing have been forget before to publish it in production.

Thanks in advance

Gilles Caulier

I close this file. all is implemented. Plugin is now open for bug report

Gilles Caulier