I don't think translators should have to deal directly with formatting.
Sometimes an artist writes one word in, say, red, and the translators colour the corresponding part of the translation. I hope that freedom's kept.
Posted under General
evazion said:
I don't think translators should have to deal directly with formatting. Ideally, they would just describe the semantics of the text using some XML-ish syntax and let the site handle the actual formatting. For example, sound effects would be marked with a <sfx> tag and the site would format them appropriately, rather than relying on translators to format them manually.
As a translator, I am very much in favour of this, bearing in mind what legga said about colours. I personally enjoy the freedom of using italics for stress, but I wouldn't mind a more standardized method.
If you're rewriting pools and favourites, you may want to keep in mind a request that has popped up from time to time; generalizing the favourite function into private pools, so a user can keep several private collections of posts. I'd find this useful for keeping track of notes, especially if I could order posts by the time of the last comment/note.
Soljashy said:
One way of avoiding this might be to have users "check out" posts to translate and allow no one to edit the notes until they "check" them back "in".
You could at the most display a warning, or you'd have to wait until the timeout to correct note vandalism.
AlexisB said:
Rule based vandalism detection
I think you could experiment with this without any server-side involvement, since most of the changes you would look at are available via the API. The only things you can't really see are changes to the parts of the side that aren't versioned, and patterns where several users come from the same IP.
evazion said:
For example, sound effects would be marked with a <sfx> tag and the site would format them appropriately, rather than relying on translators to format them manually.
This would be good.
AlexisB said:
Rule based vandalism detection
I would also make the rank of the user a criteria. I know occasionally I conduct tag gardening using tag scripts that could easily be construed by an automatic system as vandalism. If the response to the vandalism is manual rather than automatic, it mitigates the problem, but it still isn't helpful to the person clearing the list of potential vandals if most of them are well-established power users removing misused tags. Perhaps an exemption for contrib+ would be appropriate, since those are all users specifically vetted by the powers that be.
evazion said:
I don't think translators should have to deal directly with formatting.
I can understand your argument, and in general, I agree that translators shouldn't have to deal with formatting, and they don't. They can simply omit it. I can't think of any time formatting is absolutely necessary for the understanding of a passage.
On the other hand matching the formatting of the artist's original text can enhance the translation and requires the translator to have some degree of flexibility.
The easiest way to do this without re-inventing everything is to allow the translator to define the CSS style directly by some mechanism. Otherwise we would need to provide our own means to vary font color, size, weight, face, background, etc.
Updated
Things I'd like to see:
Translation note copy feature: Automatically copy the notes from one picture to another, placing them in the same relative pixel area. Would be most useful for things like marriage_certificates, ear_charts, etc.
Translation votes: This was suggested before (forum #10038) and I think it's a good idea. Basically, there's an interface that says "Does this post need translation? yes/no". For every user that clicks "Yes" some counter goes up, like trans_req:+1 or something. Then potential translators could look for the posts that the most people want translated by searching this metatag, like they could search for touhou order:trans_req. And then once the post is translated, people could then change their vote to "No" and the trans_req counter would go down. This would solve the problem of some people tagging pictures with translation_request when it's just some random sfx like post #562607. For every person who sees that and thinks "Dude what is that hamster saying?" there'd be five people who could recognize it as sound effects and vote "No".
Updated
Shinjidude said:
I would also make the rank of the user a criteria.
The users could get some multiplier to make the system a bit more gracious while interpreting the actions. But excluding this users would be somewhat contra productive, because nobody is immune to a spontaneous seizure of butt-hurt.
Log said:
You can't actually use the dropdown to change ratings or use tag scripts below priv anymore so this point is kind of moot.
Well, it's not like vandals are too stupid to use some neat scripts for their tampering.
Aside: I miss the tag script feature. :/
jjj14 said:
Translation votes
Great Idea!
memento mori:
If two people add new notes at the same time, neither of them will notice until they reload it some random time later and see two sets of translations.
It's a race condition. Any time you open a page intending to edit something it's possible for someone else to edit it first, in between the time when you first opened the page and when you submitted your edit. This is most likely to occur when editing notes or tags, but it can also potentially occur when editing anything else: pools, artist entries, wiki pages, etc.
One solution is to use conditional PUTs. Basically, the client sends a If-Unmodified-Since header with the request. The update only succeeds if the data hasn't been modified since you originally loaded the page. If it has been modified, then you get an error and you try again.
(On a related note: it might improve performance somewhat if Danbooru took better advantage of conditional GETs)
To the extent that people upload multiple-page comics as pools, a mode that can switch between images with AJAX loading to flip pages would be nice.
AJAX style loading would be useful in other areas as well. In particular:
Another thing I'd like to see improved upon is the PM (or mail) system:
Deleting personal messages: One feature I've always felt was missing was the ability to delete messages sent to you. This would definitely be something I'd like to see implemented someday, as it seems to pretty much be a standard feature for virtually all PM systems, but is mysteriously absent from Danbooru (as well as all of the other image boards forked from its code).
And maybe the way you're alerted of unread PMs could possibly use some tweaking, too. While the big "You have new mail" (or text similar to that; I forget) banner is a very effective way to alert you of new messages, I've heard concerns that it can become intrusive to the browsing of the site if you're a person who's sent messages on a regular basis. I would imagine this might be the case for some of the mods.
While that last issue isn't particularly a problem for me, I thought it was worth throwing out there anyway.
Updated
Random synapse firings regarding nesting/grouping tags:
Technical feasibility not taken into account since I'm not huge on databases etc.
You know how you can tag people in photos on facebook by drawing a box around them - you could tag sections of an image this way and somehow weight search results for multiple tags towards images with them in the same box first. Alternatively weight by the size of the box compared to the size of the image to give a lower search priority to smaller background characters than the main focus of the image. Even if possible it would completely break danbooruup of course, unless the image could go into a staging area after upload and prior to tagging.
Another way out in the blue sky idea:
It could be interesting to see how well facial identification to suggest tags could work on anime art - Picasa 3.6 pulls up a number of characters but it doesn't have access to my huge Danboooru folder. Or, when entering hair and eye colour, it could suggest the few most popular characters with those tags, then suggests related tags.
Actually, I skipped a few posts and Shinjidude has mentioned some similar ideas already. Regarding descriptive tags, ISTR a long time ago suggesting making colour and other descriptive tags a subtab and adding types for clothing and body parts etc. I also have a vague memory of Albert saying something about tag orphogonality in the past - I can't find it in the forums here so it may have been on traq or even on rasberryheaven.
I sincerely apologize for not being able to read all posts above now.
I have been thinking of one little handy improvement for a good while.
When browsing a Danbooru pool pic by pic, we have a header bar with these nifty "button" arrows, e.g.:
Pool: << Disgustingly Adorable >>
I would love to have those browsing arrows at the top of the page when going through any given set of images on Danbooru. (All) posts, my favorites, any of my subscriptions, the results of any search, you name it.
Sometimes you feel no need to look at the thumbnails, but instead want to go through the whole set (or at least a good number of pics) in sequence.
zatchii said:
(...) I'd find this useful for keeping track of notes, especially if I could order posts by the time of the last comment/note.
I support any ideas to make comments more easily browsable.
Hmm, this is way way out in left field, but it just came to mind again so I thought I would throw it out there.
Back when Danbooru closed to the public, it closed for a number of reasons, but one of the reasons was a spike in bandwidth and workload on the server. At that time I had imagined what it would take to make a decentralized Danbooru that worked solely via client machines (sort of like a P2P app, or bit torrent's distributed hash tables, but with the indexing Danbooru provides). This would shift some of the workload, storage, and bandwidth to the users.
If there are good ideas that required more oomph than the server could put out en masse, would there be a way to offload it to the client? This could be done either via a stand-alone application or an embedded java / flash / what-have-you applet.
Unfortunately most of the bottle-necks I see right now are database based, and that couldn't be done remotely without a copy of the database to work with. Perhaps something like a DHT or rsync could be set up to distribute the non-personal information in the database for personal use via client? Of course then you end up with portability issues, and usability issues for low-end and casual users who perhaps couldn't care less anyway.
Related to this, I have in the past considered what a good Danbooru client application might look like. It'd be a huge step in the wrong direction as far as web 2.0 is concerned, but it would allow for more expensive operations to be run without harming the centralized server.
Like I said, way off in left field, but they are ideas I've thought about in the past and never shared, so I thought I'd throw it out there.
Updated
A couple more ideas:
Embeddeding more metadata for various pages using HTML 'link' elements: On the post index (or paginator), we have <link> elements describing the 'Home', 'First', 'Previous', 'Next', and 'Last' page relationships. What I'd like to see is the use of page/post relationships in this manner when visiting individual posts, and possibly other parts parts of the site.
For example, if a post has a parent, the parent post could be linked-to with the 'Up' relationship, and sibling posts could be mapped to the 'Next' and 'Previous' relationships. Respectively.
This could somehow be incorporated for viewing posts that are in a pool too, as pooled posts have clear-defined relationships. And the reason I say 'somehow' is because you can't view an individual post in a pool-only context, so that wouldn't exactly work - but I'll just throw the idea around anyway; the more metadata, the better.
Giving a warning when a post's parent or sibling posts are in your blacklist: Currently, when you're viewing a post that has a parent and you click on the 'Parent' link, your tag blacklist will be bypassed. The same applies when clicking the 'Previous' or 'Next' links, the '<<' or '>>' links (when a post is in a pool), or even the 'Random' link.
Because of this, I completely avoid the use of the aforementioned features, since I'm rather not interested in taking the risk of blindly stumbling upon content I would've been much happier not seeing in the first place.
And if applicable, posts linked using the 'post #nnnn' syntax could be rigged with a warning as well.
Had a thought about adding posts to pools. Again if this has been mentioned I apologize.
When you want to add a post to a pool you get the basic list starting with "a". Is there a way to sort the pools so that ones related to the artist would show up first and the most recent ones would be at the top of that query?
You would still get the emotion pools but at least when adding an artists new image to his/her existing pool it would be faster.
AlexisB said: The users could get some multiplier to make the system a bit more gracious while interpreting the actions. But excluding this users would be somewhat contra productive, because nobody is immune to a spontaneous seizure of butt-hurt.
Well, you'd at least have to exclude me and albert, or aliases and implications would be an instaban. =P
Okay, that's just stating the obvious but any limiting would have to be very carefully implemented. There are users who run scripts to fix tags or source URLs, there's mass editing, there's clicking really really fast with tag scripting, etc. Placing any limits at all on janitor+ would be more trouble than it's worth.
Bapabooiee said: Another thing I'd like to see improved upon is the PM (or mail) system:
Deleting personal messages
I'm the kind of person who would never delete any of my dmail (all 100 pages of it, 41 of which are pixiv url related), but I have always been a bit confused by the lack of that feature.
One thing I'd really like to make the search option (which I love) even better is to be able to search "From" and "To" fields in the same search. I've wanted this quite a few times while doing pixiv url emails. Running two searches (one to see if I've emailed the person before, another to see if they'd replied) can get time consuming with so many emails to send.
And maybe the way you're alerted of unread PMs could possibly use some tweaking, too. While the big "You have new mail" (or text similar to that; I forget) banner is a very effective way to alert you of new messages, I've heard concerns that it can become intrusive to the browsing of the site if you're a person who's sent messages on a regular basis. I would imagine this might be the case for some of the mods.
Well, it does get me to read my mail almost immediately after seeing it, I'll tell you that much. Especially because I use a black background for danbooru and that green really assaults my eyes.
The downside is that my only option is to read (thus mark read) the posts and reply immediately (not always feasible). Or, mark them read to make the banner go away, go do whatever is is that was more pressing, and then hope I don't forget about the mail in the meantime.
I have a similar issue with the forums, where things will often get marked read before I've actually read all the threads (often if I reply to something else). I usually can work around this by just paying more attention to the time stamps but it does cause me to miss threads sometimes.
Another idea I had previously that popped back into my head: try using tf-idf to compute a tag's relevance rather than a simple count of co-occuring tags.
Doing this would allow us to order tags by their relevance and specificity to the current query (terms that are much more common for the query than they are in general get weighted higher) and limit the bias we currently have towards very common generic tags such as breasts or long_hair that show up as co-occurences to almost everything, but provide very little meaningful information.
This technique could also be used to improve the "related tags" feature.
Another thought from my perspective as a new user. Would adding tool tips be useful or even possible? A lot of stuff is fairly obvious but for example parent/child is somewhat less.
Just thinking of more stuff right at the users fingers vs using a faq or even having to dig deeper into the help files.