Danbooru

Idea: Artist commentary field(s)

Posted under Bugs & Features

Going through lots of Hammer's works, I've noticed that they frequently post commentaries to their images, and when new images, somehow linked to one already posted, appear - the commentaries get updated with said links. The current practice for artist commentaries is to post them as a comment, and the translation tends to be another comment, since apparently many of the posters don't into Japanese (like yours truly). This might pose a few problems (this might be an exaggeration): the updated commentary needs to be posted in some bizarre way in another comment, with no normalized/standardized way, similarly the translated commentary. Then there are comment limitations, ie. I'm currently waiting for about an hour to pass to be able to post another commentary because my two comments per hour are currently spent on two others.
In that case, would it be possible (it's a silly question, I know it would) would you be so kind as to implement the fields for artist commentary, possibly one for original language and another for English translation?

I could go for a means of adding commentary aside from my rote memorization of Dtext. But I get the feeling that some of the asterisk'd tags (which can be commentary in themselves, particularly from Tumblr) from Pixiv come in later, possibly automated or by users (there's still a lot about that site I don't know how it works). Definitely would need a "time of retrieval" on display. Then there's images that're hosted at multiple sites (ex: Tumblr, Hentai Foundry, Pixiv combo), each with varying "commentary".

Yeah, finding the best-looking version of a pic's a bit easier than this textual transcription'll be. I still struggle to figure how to handle emoticons (and to a lesser degree, account images) from deviantART. Oh, and then trying to get Dtext to work well with URLs that're too close to other text (I just copy+paste a Notepad "tab" in 'ere, even if there's a...non-breaking space? Looked like a spacebar-space, but didn't act like it after previewing).

</babbling>

This has my wholehearted support. I'll add a few more reasons why it's a good idea:

1. The commentary, or its translation, could be buried deep within the thread. Example: post #1482567. Pain in the ass to scroll through and find the translation. You can't just press the end key because it's not necessarily at the end, and there's no way to Ctrl-F it.

2. After translation, the Japanese commentary is no longer useful to the vast majority of users, yet in the current systems it takes up the top post in most cases.

3. Sometimes the translators makes mistakes (guilty here). But there's no way for the community to fix the commentary translation other than replying with "Fix'd" or "Hey, you made a mistake there". Then it's up the translator to check whether anyone made a correction and update their post.

NeverGonnaGive said:

All excellent ideas but I think we should just focus on a single commentary field in the first iteration. That should cover about 98% of the use cases. No tags and no multi-site stuff in the first iteration. After all the bugs are flushed out and everyone's comfortable with it then we can add the extra stuff.

Type-kun said:

This saddens me a bit, and is more or less far from my expectations. There's no need to make it a compulsory field, or information grabbed from the site, as the sources may (and will) vary, thus (as mentioned) adding unnecessary strain on upload. All I'd expect is just a separate field, dedicated just to the artist's commentary. I don't see the need to make it overly complex, and if that's what I should do, I could open an issue on GitHub with the idea.

HaxtonFale said:

This saddens me a bit, and is more or less far from my expectations. There's no need to make it a compulsory field, or information grabbed from the site, as the sources may (and will) vary, thus (as mentioned) adding unnecessary strain on upload. All I'd expect is just a separate field, dedicated just to the artist's commentary. I don't see the need to make it overly complex, and if that's what I should do, I could open an issue on GitHub with the idea.

well, but you see, that itself is more information for database to handle, ironically.

That being said, I think current comment system is fine. That was what it was supposed to be used for. Surely, later, maybe we can "name" every image but even in long-term, we really don't have usage for that, do we?

At the least, would we be able to request (or, if of a certain level, mark ourselves) a comment as one of commentary or translation thereof? It could have a faint highlight (or...backlight? backdrop?), or be bumped to the top (but retaining its timestamp). What might work best is a collapsible (or otherwise partitioned) "Commentary" section where duplicates of such user comments are set on display.

[IMAGE]
Comments Edit Share
WANING
Commentaryv
-------------
[comment 1]
[comment 2]
[comment 3 - relevant]
[comment 4]
...

Commentary^
[comment 3 replicated]
-------------
[commen...

Personally, I think the "expand" DText thingy has helped greatly with putting the commentary in comments, though it seems lots of translators don't understand how to use it (or simply don't bother) and either make a weird broken quote or simply stuff the translation in old-fashioned style.

HaxtonFale said:

Then there are comment limitations, ie. I'm currently waiting for about an hour to pass to be able to post another commentary because my two comments per hour are currently spent on two others.

Just as a note (as some people don't know), unless it changed with Danbooru 2.0 (I've been Gold since before it came around so I wouldn't notice), you can only bump two comments in a certain amount of time, but you can post an unlimited number of unbumped comments. The only difference is that bumped comments move the image to the top of the Comments page. While that may help people in noticing the commentary, it isn't a vital piece.
If it has changed to limiting to two total comments, I vote to revert. But that'd be another thread.
(More parenthesis, captain!)

At the least, would we be able to request (or, if of a certain level, mark ourselves) a comment as one of commentary or translation thereof?

Then how about giving builders+ an ability to mark comments (including other's comments) as artist commentary/translations, so that they stay on top? That puts little additional strain on database.

Before spending an entire page discussing alternatives to a system that was thought up a day ago you guys may want to make a ticket and see if either of the coders is willing to take it on in the perfectly fine (and honestly what sounds to be perfectly doable) state that the OP referred to. This is being way overcomplicated immediately.

Log said:

Before spending an entire page discussing alternatives to a system that was thought up a day ago you guys may want to make a ticket and see if either of the coders is willing to take it on in the perfectly fine (and honestly what sounds to be perfectly doable) state that the OP referred to. This is being way overcomplicated immediately.

OP created a ticket on github

I agree, we should all just sit tight and let the devs work their magic. Further brainstorming will only overcomplicate things.

What "database strain" are you guys talking about? Why would this new field cause performance problems if it's not even going to be indexed for searching?

Anyway, let me summarize the benefits of this field over the current comments system:

  • The commentary field would be editable by anyone. So for example User A could put the untranslated commentary in it, User B could translate it and replace it with the translated commentary, User C could correct an inaccuracy in B's translation, and User D could fix a grammatical mistake. Rather than awkwardly taking 4 different comments, this only uses one field.
  • This field would be displayed in a fixed place somewhere, like maybe right above the comments. Therefore, it wouldn't get buried under a bunch of other comments.
  • Basic members trying to translate or post untranslated commentary won't have their productivity limited by the 2 bumped comments per hour limit.

I can think of one problem though: Some users might get the idea that every single image needs to have its title/description copied over to the commentary field, even though a lot of these don't say anything interesting. Having this field filled with clutter like "untitled" or "lol i just felt like drawing this" or whatever would reduce its usefulness and just be a pain for both uploaders and readers alike.

Updated

What "database strain" are you guys talking about? Why would this new field cause performance problems if it's not even going to be indexed for searching?

Seeing how Danbooru keeps track of all kinds of post changes, I can see how this might be an issue should an extremely efficient system of keeping track of changes in text of arbitrary length not be designed and implemented :P Especially since the commentary might become a subject of abuse, you'd like to be able to at least see who committed changes, if not see the changes themselves. This part depends on how much database space for plaintext Danbooru has (and is willing to offer to the new feature over, say, forums).

Nonetheless, I'll vouch for the feature (d'uh), including multiple commentaries per image (multiple languages), with an option of moderated or locked commentaries (respectively, submitted commentaries must be first reviewed and no one below janitor/mod can submit commentaries). Should the need arise, I can even go and add Ruby to my portfolio just for the purpose of adding that :P

  • Basic members trying to translate or post untranslated commentary won't have their productivity limited by the 2 bumped comments per hour limit.

You'd still want to restrict them somehow, for the reason(s) stated above. Though a separate (and higher) counter should suffice. I think. I never ran this kind of community thingy.

HaxtonFale said:

Seeing how Danbooru keeps track of all kinds of post changes, I can see how this might be an issue should an extremely efficient system of keeping track of changes in text of arbitrary length not be designed and implemented :P Especially since the commentary might become a subject of abuse, you'd like to be able to at least see who committed changes, if not see the changes themselves. This part depends on how much database space for plaintext Danbooru has (and is willing to offer to the new feature over, say, forums).

If we decided to store each change to commentary in post versions, it would work similarly to wiki pages. Wiki pages store arbitrary-length plaintext, and wiki page versions keep track of each individual change to it, and there don't seem to be any performance/disk space problems there.

And there are only ~4000 posts under ~commentary ~commentary_request; all other posts and post versions would leave this field blank. The database space this would use is very small. It's not as if all 11 million post versions would have this field filled out.

But even if we didn't want post versions to store these changes, an alternative would be a simple "was the commentary changed?" boolean field on each post version like you mentioned.

HaxtonFale said:

Nonetheless, I'll vouch for the feature (d'uh), including multiple commentaries per image (multiple languages), with an option of moderated or locked commentaries (respectively, submitted commentaries must be first reviewed and no one below janitor/mod can submit commentaries). Should the need arise, I can even go and add Ruby to my portfolio just for the purpose of adding that :P

This seems to be overcomplicating things quite a bit. I don't think the idea of filling the post editing area with a dozen new fields just for commentary (which only affects a small percentage of posts) is very user-friendly.

I think just one field and without any locking abilities would suffice. Even if it turns out some changes are needed it's not hard to add them later.

HaxtonFale said:

You'd still want to restrict them somehow, for the reason(s) stated above. Though a separate (and higher) counter should suffice. I think. I never ran this kind of community thingy.

Why should they be restricted?

I agree about the space requirements, if the post count is so low, although I sometimes traverse through older (?) Hammer's images and find posts with not posted commentaries (but I don't expect these to be large in numbers anyway).

But even if we didn't want post versions to store these changes, an alternative would be a simple "was the commentary changed?" boolean field on each post version like you mentioned.

Why should they be restricted?

The problem here would be finding an offender to some sort of trolling edit, or possibly rolling it back. This is what I'm mainly concerned about.

This seems to be overcomplicating things quite a bit. I don't think the idea of filling the post editing area with a dozen new fields just for commentary (which only affects a small percentage of posts) is very user-friendly.

I think facilitating multiple commentaries would simply require one option to add a commentary, which spawns a form with a field for language and the commentary itself, and another option to edit an existing commentary, e.g. in form of a link beside one.

Crossposting from Github:

I don't like it for a few reasons:

  • We're adding a new field to a large table for something that only affects a very small subset. To me this is a code smell.
  • If the field is normalized to another table you're adding another database query to check for it.
  • You would have to add a new field to the upload page that for the vast majority of users would be left blank. So it just takes up space and adds visual clutter. The Upload/Edit pages are already cluttered enough IMO.
  • If anyone can edit this field, then it has to be versioned because of vandalism issues. This just adds to the complexity.
  • I think most users agree that the comment system is adequate most of the time. Is the added complexity of a new field worth whatever advantages it would grant?

Some alternatives:

  • Maybe the comment bump should be tweaked instead.
  • Maybe janitors should be given the power to promote comments so that they appear first (and delete outdated/incorrect translations and commentaries).

After further discussion this feature was added. Thus I recommend people use this instead of comments from now on.

You can add or edit the artist's commentary for a post by clicking "Add artist commentary" in the sidebar. Afterwards it will appear under the image.

Updated

And after I'd become confident in my ever-tweaked personal methods. Ah well... Guess I'll go back through my uploads whenever the cataloging itch bites me again.

EDIT: *checks it out* What should I do when there's multiple hosts of the essentially same image, all with varying information? This especially when the used source (for picture size/quality) has the least useful commentary? And how should timestamps, tools, and tags be handled (all of which I see as pertinent, the foremost when there's a large gap between the original and the Danbooru upload, and the latest are sometimes a commentary in themselves)?

Toks said:

After further discussion this feature was added. Thus I recommend people use this instead of comments from now on.

You can add or edit the artist's commentary for a post by clicking "Add artist commentary" in the sidebar. Afterwards it will appear under the image.

Nice. Was getting tired of writing out the commentary in DText.

NeverGonnaGive said:

What should I do when there's multiple hosts of the essentially same image, all with varying information?

Couldn't you just put both? Do seiga: blah blah. Pixiv: blahblah.

1 2