Context url?

The source url is supposed to point to an image's original address, and it's filled in automatically when uploading by url. That's the way we like it, but often we want to see the page an image was originally posted in, and it's not always easy to go from the url of the image to that of the page. Actually, it's never easy: it tends to range between tedious and impossible. How about adding a context url field, then? For examples, images that come from blogs, we could put the url of the blog entry in there (useful if you want to read the artist's comments); for post #380315, it would be an url to the auction; and so on. A Firefox extension for uploading to Danbooru could even fill in the url automatically, in many cases. The pixiv url filter thing could be changed to write to the new field, too.

This is a great idea and I support it in principle, but unless it's automatic, I don't foresee many people filling it in. I use the bookmarklet, and what I usually do is I drag out a bunch of images into a new window, and then bookmarklet them all. In some cases, it would be quite difficult to retrace my steps to find the context URL. I could change if necessary and I would, but there are likely to be people uploading to danbooru that are less inclined to be accommodating in that regard. I suppose it's not a super-essential field, but still.

... Which makes me wonder how many people are using the FF2 plugin vs. the bookmarklet, is there a statistic of that?

Anyway, I think it's a good idea.

Why not just post these URLs as a comment instead? It would achieve the same thing. I can't think of any reason why it needs to be built into the site, other than it maybe being a little bit more convenient to input for uploaders.

That's cluttery though, not to mention highly impractical since it would mean adding a comment to practically every image you upload that isn't from Pixiv. Granted, for a number of uploaders on Danbooru that's the same as saying "none of them", but for me and albert at the very least that's not the case.

This has been brought up a number of times before though always buried in longer threads. I certainly still support the idea in theory, but don't think many people would understand the concept or do it correctly.

I upload with danbooruup (the FF2 extension). One problem for me is that it hasn't even been updated for FF3, and at this point I presume is abandoned and never will be. So I highly doubt we'll ever get an update that incorporates this extra source field. But I'd still fill it in manually after I upload.

The number of cases where it's useful are limited primarily to blogs, though. In many cases, there's no specific "blog post" type page to link to, and the main link to the artist's website in the artist wiki entry is as good as anything we could put in this new source field.

For the others, pixiv is covered already. I find the percentage of my pixiv vs artist homepage uploads skewing in favor of pixiv more and more. This is because increasingly more artists get in the (unfortunate, if you ask me!) habit of 1) uploading their images to pixiv first, occasionally days ahead of their own website, 2) uploading larger versions only to pixiv, or 3) uploading clean/textless/uncensored versions only to pixiv. And then there's all the pixiv only artists.

So we're basically down to blogs, and a few small exceptions like linking to a specific gallery page for artists who have multiple galleries. This is still a decent amount of uploads though, so again I still support this idea.

But who is going to use it, other than those of us posting in this thread and a couple more who read it? We would also need some basic safeguards in place so people aren't able to mix the two up and screw up find artist and such.

evazion said:
Why not just post these URLs as a comment instead?

Comments aren't searchable, the source field is.

Would be nice if we could add an arbitrary list of URLs, similar to the artist entries. Most posts would only have one (if that), of course. Making the source field a bit taller shouldn't be too confusing.

'Find artist' should check all of the links, or the one where the cursor is. Similar to how 'Related tags' behaves.

There can be multiple correct image URLs. Some pictures are posted on pixiv as well as the artist's homepage, and some change path or filename when the site is reorganised.

One more scenario: When an image already exists on danbooru and someone tries to upload it again, the tags are always merged, but the new source is only added if the source field happens to be blank. So a post with useless "Image board" filler text will cause a new, correct URL to be discarded.

If you allow multiple sources, any new ones can be appended instead. Although you'd have to filter out duplicates.

I think that creating an additional source field is a bad idea, and that extending the existing source field to allow several URLs is a good idea.

aldeayeah said:
I think that creating an additional source field is a bad idea, and that extending the existing source field to allow several URLs is a good idea.

\\
Agreed. Kind of like the URL fields for artist pages.

The benefit of having a second field is that you know exactly what both URLs are for. Having multiple without explanation could be confusing. I also wonder what it would do to Find Artist to have multiple URLs associated with an image? It's a lot simpler if it's only looking at one specific field.

The idea has benefits, but one big one (adding more than two URLs) would practically never get used. Where it's better than having a separate field is that users don't have to try to figure out which link goes where, but the preciseness of having two fields with set purposes kinda wins out for me.

Neither is perfect though, simply because users will find ways to screw up anything

The idea has benefits, but one big one (adding more than two URLs) would practically never get used.

Well, there's a common case: an artist that posts the same image in his personal web page and in Pixiv.

And storing alternative sources when people make duplicate posts is a neat idea.

Having a single multivalue field preserves the current interface and minimizes confusion, although I think you're right when you say that it's harder to implement.