Additionally, I'd like WakabaMark to be fixed somehow.
I don't know how, though. You know my resentments.
Finally, thanks for your fine work throughout all this time.
It is appreciated!
> They can modify it an claim copyright on their modifications, at least as long as they're significant enough, but that doesn't affect existing works in the public domain.
Devil's advocate: What if they make significant changes you would want to add yourself? before you do? Can they then tell you to stop if they license their work first?
> Also, I'd like to ask exactly how Kareha does automatically generates deletion passwords. I'm guessing it's similar if not identical to how it creates ID session codes with a user's IP.
Actually, no, the Javascript just strings some random numbers and letters together.
> Because it's one of the two requirements for creating a new thread, and it's a lot more important to have a well-defined topic than to fill in your name.
But the body text is even more important, and that goes at the bottom. So I dunno.
>It's more convenient if you want to start a new thread, but for those who don't it's one more form to have to scroll by.
Would it maybe make sense to make a separate thread creation page?
On second thought, the whole search idea was pretty poor...but could you implement saging in a way that's independent of any particular post element, and is instead assigned in the individual templates?
http://en.wikipedia.org/wiki/Public_Domain
It means anyone can do whatever they want with it. They can't claim copyright, though, since they didn't create it in the first place. They can modify it an claim copyright on their modifications, at least as long as they're significant enough, but that doesn't affect existing works in the public domain.
> This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.
There's no obvious way to do this, since there has to be code that specifically checks a field and takes certain actions long before the template comes into play. It'd take some sort of plugin system to implement it, and I don't think that's quite called for.
Also >>154 is Kami.
>>184
If people are going to decide to use custom names for paramaters, then there isn't much you can do about it anyway, or is there?
>>151 It's all public domain, I believe.
n is implemented, but not for >> yet.
Also, >>1 is, as it is, only added to URLs of the form xx-yy and lxx. 2ch doesn't add >>1 for single-reply URLs, and if you're using commas, I figure you can add >>1 yourself if you want it. I'm not sure if this is the best behaviour, but that's how it works at the moment.
No, that's just plain wrong. It is very much the job of the programmer to decide on such issues, and make sure they work consistently across boards.
I was browsing through some old threads and now they're all gone. :(
> Thorough search functionality a-la notchan, using PATH_INFO. This might not be possible without implementing a per-post metadata system though.
I think this not something that needs to be part of the software itself.
Besides, Google mostly provides that function just fine with site:blahblahblah.com blah
Also, what is "user deletion"?
> Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess.
Why? Let people figure out things themselves, if they are so keen on changing their keywords. They can get together in their own webmaster threads and figure this out. I don't see why this should be solved here.
Of course I think this is a dumb idea in the first place. Nobody needs to know what fusianasan and sage are. Write a FAQ with two sentences about it and/or let your oldtime users tell newbies. Two frickin' words, and you people talk about it as if it were something like making up a new system of romanization!
> Then why not simply boil it all down to the comment field, with trigger strings for inputting the name, e-mail, sage, ID:Heaven, and fusianasan? You can get a lot more minimal with the current interface.
That's a bit too much. You want to talk about sage and fusianasan in the comment field, not trigger it with it.
I suspect you are joking here, though. Design is about what you can take away and still remain optimal conveniency/efficiency on the user part, not about taking as much away as you are technically capable of.
>>71
forgot to add that turning the CSS selector and Admin functions into drop-down menus and moving them to the right side of board and thread title headers would remove that top bar entirely on the front page.
>> config.pl parameter to permasage after a certain thread filesize/total number of characters has been reached
> Isn't this essentially the same as saying "Please don't talk so much?"
I am not >>208 but the first who suggested this here (long ago). I think it may be vital for future, actually popular boards to limit the filesize of a thread so that the board won't get hammered by repeated loads of whole threads without having to limit the size of posts themselves something fierce.
test2. looks good!
Hmm, looks like my ISP fails at keeping my IP secret.
And my post ist a good example for chosing the wrong markup :/
About rel=nofollow: What links should have it? Obviously not the "entire thread" link, but the l50 links in the thread list sort of need it, otherwise the search engine will never find them in the first place. But that means the l50 links will end up in the index.
Weird, ¦ now stays ¦.
Testing #¦ now.
>Let people figure out things themselves, if they are so keen on changing their keywords.
If you really want to use your own custom trigger strings, you can easily search kareha.pl for instances where "sage" and "fusianasan" are used in that context and either replace them with those custom strings or append them as secondary strings. It's not something that warrants additional config.pl parameters.
fusianasan + sage test
Apparently it's not Japanese, because it's supposed to be pronounced as an English word. I have no clue, though.
> Right, I guess it was dumb to mention 0ch/Futaba in the first place. The point is, as you said yourself, tripcodes are a gimmick, and if someone wants to maintain a persistent identity across multiple boards and sites (ie, everyone here with a tripcode), they have no choice but to use ordinary tripcodes. Secure tripcodes are useless because they limit your identity to a single board, supposing each board/site's cipher key is different -- which it should be, since that's the point of having a secure tripcode in the first place. No one should be so paranoid about a tripcode that they'd need to have a different one per board/site.
True, they're of limited usefulness, but people like admins might prefer to use them. And there are certain cases were you might use them temporarily for various purposes. I wrote the code already, so I might as well leave it in. It has some uses at least.
> Shouldn't we sacrifice some backwards compatibility for a more robust and scalable design? It might even be possible to provide an upgrade.pl for old threads.
I think I'm too lazy to do it. It's kind of hairy. Besides, as I said, you can remove a lot of the drawbacks of seprate installations by using symlinks.