Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better upload API #17

Closed
HarelM opened this issue Sep 8, 2017 · 8 comments
Closed

Better upload API #17

HarelM opened this issue Sep 8, 2017 · 8 comments
Assignees
Labels

Comments

@HarelM
Copy link

HarelM commented Sep 8, 2017

When using the wikimedia common upload wizard the following fields are editable:

  1. Tags
  2. Geo Location
  3. Description
  4. Date
    Would be nice if the client FilePage.Upload would support those as well.
    UploadResults object has a fileKey which is good in order to get the file etc, but a full address to the file would be helpful too, as I guess in most cases people would use the link to present the image.
@HarelM
Copy link
Author

HarelM commented Sep 8, 2017

Some usage issues:

  1. FileKey is returning null after successful upload.
  2. When using a title that does not stat with "File:" when uploading a file the API throws an exception - would be better to either allow the developer to set the namespace by adding a parameter to the API call or add it automatically.

@CXuesong
Copy link
Owner

CXuesong commented Sep 8, 2017

For issues related to Wikimedia Commons, I have a hunch that the actual Tags, Geo Locations, Descrptions and Dates are all on Wikidata, which is actually out of the scope of my little project. (Sorry; but you can try to write one using WikiSite.PostValuesAsync to post requests) Even if it were to made into a part of the library, it would be in a different package, because it's Wikimedia-specific.

For example, c:File:Forbidden City Beijing Shenwumen Gate.JPG is related to d:Q2047427 (see image section). The former does not have any of the properties as you mentioned; but the latter does.

@CXuesong CXuesong self-assigned this Sep 8, 2017
@HarelM
Copy link
Author

HarelM commented Sep 8, 2017

I see your point. It's possible using the comment string to place wiki data. I can agree it might be out of scope for this project, the rest is still relevant though.

@CXuesong
Copy link
Owner

CXuesong commented Sep 9, 2017

Sure, I have just looked into this…

FileKey is returning null after successful upload.

The FileKey property is only used for Continue and Warning states. Only in that case, you might have the need to include the value of this property in the filekey attribute of request JSON in the next upload. For example, you wouldn't need to upload the file again, if you are trying to upload a duplicate file with a different title and without ignorewarnings turned on, the API response will return something like this

{
    "upload": {
        "result": "Warning",
        "warnings": {
            "exists": "Test_image.jpg",
            "nochange": {
                "timestamp": "2017-09-09T17:19:55Z"
            },
            "duplicateversions": [
                {
                    "timestamp": "2017-09-09T17:18:43Z"
                },
                {
                    "timestamp": "2017-09-09T17:16:06Z"
                },
                {
                    "timestamp": "2017-09-01T11:42:01Z"
                },
                {
                    "timestamp": "2017-07-11T15:23:46Z"
                },
                {
                    "timestamp": "2017-07-11T14:54:25Z"
                },
                {
                    "timestamp": "2017-07-01T07:29:21Z"
                }
            ]
        },
        "filekey": "155v0844eoek.n3tctb.6332.jpg",
        "sessionkey": "155v0844eoek.n3tctb.6332.jpg"    /* For backward compatibility */
    }
}

Then you may turn on ignorewarnings, and upload again. In this case, you just need to specify filekey instead of attaching the content of the file, again. With WCL, you can pass in the last returned UploadResult instance and speciify ignoreWarnings to true.

@CXuesong
Copy link
Owner

CXuesong commented Sep 9, 2017

When using a title that does not stat with "File:" when uploading a file the API throws an exception - would be better to either allow the developer to set the namespace by adding a parameter to the API call or add it automatically.

I will fix that. If you are not explicitly specifying namespace, the method should assume you are using File: namespace.

CXuesong added a commit that referenced this issue Sep 9, 2017
Add documentation for UploadResult.FileKey.
@CXuesong
Copy link
Owner

FYI, mw:Wikibase/API has some explanations on Wikibase API, such as wbeditentity, wbcreateclaim, and other related APIs. Actually they an entirely new set of APIs, so it's possible that they would be made into an API library. Though it would be good to have but I'm not sure when it may be included into WCL. Until then, I'm afraid you need to write your own API invoker, though you may use WikiSite.PostValuesAsync to reduce the work to do.

My rough idea is to create something like WikiEntity and expose the APIs just like WikiPage, and they (possibly, I hope) can share a same type of WikiSite.

@CXuesong
Copy link
Owner

CXuesong commented Oct 14, 2017

Uhmmm, I didn't took a thorough walk-through on uploading a picture to Wikimedia Commons until I found out a test site for it. It's not until then did I realize that I really have misunderstood something… For example that the geo location has nothing to do with Wikidata.

So you just need to use appropriate templates on the description page for them, for example

=={{int:filedesc}}==
{{Information
|description={{en|1=English description}}
{{zh|1=汉语描述}}
|date=2017-10-01
|source=Source URL here
|author=Author name here
|permission=
|other versions=
}}
{{Location|12|23}}

Fill in the blanks, and it's done. Sorry for the confusion I used to cause…

However I have already written a Wikibase API client and there's no way going back.

@HarelM
Copy link
Author

HarelM commented Oct 20, 2017

Thanks! I have updated to latest version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants