95

If a comment has [short title](http://lo-o-ong.example.com/url) link, then http://lo-o-ong.example.com/url is counted towards the total comment length limit.

The answer to the same issue (to ignore the link URLs) is: the current limit is enough, or to span a comment over several physical comments, or to use URL shorteners.

The current limit is especially limiting for non-English URLs. Compare the markdown for:

[link](https://en.wikipedia.org/wiki/Computational_complexity_theory)

vs. the same article in Russian:

[ссылка](https://ru.wikipedia.org/wiki/%D0%92%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%81%D0%BB%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C)

Splitting manually into multiple comments due to a long URL is busywork -- if a computer can do it; it should do it for you i.e., if the database limit for comments can't be increased, then let's allow the JavaScript to submit multiple comments. It could be restricted only to the case when the reason that the comment exceeds the size is a long href (visible comment text is under the limit), to avoid encouraging flooding (a very simple implementation will do -- it is enough if it works in the common case).

Shortened URLs are bad. Writers have to obfuscate their URLs. Readers don't see where they go. Links often serve as a reference to additional material so we shouldn't discourage comments that back up their statements with references.

How different is this Russian Wikipedia link from an obfuscated one?

The rendered version looks like this: ссылка. Hover over to see the decoded url: http://ru.wikipedia.org/wiki/Вычислительная_сложность (it is clear if you know Russian — the assumption is that the links are used on Stack Overflow на русском where people do understand Russian) that it is less obfuscated than a shorten url e.g., ссылка (https://goo​.gl/DPvnVF).

Improve this question
10
  • 4
    This is a good suggestion and makes perfect sense.
    – paulmz
    Oct 3, 2015 at 15:28
  • 5
    How different is this Russian Wikipedia link from an obfuscated one? Not everybody can map arbitrary ASCII/Unicode numbers to the characters in a foreign language just by looking at the escape codes.
    – Deer Hunter
    Oct 3, 2015 at 20:23
  • 6
    The only thing I could see going wrong is that this would be that I could then post 1000 links in a comment and... well you get the idea.
    – Diminutive Colossus
    Oct 3, 2015 at 23:05
  • 9
    @DeerHunter: obviously, browser decodes percent-encoding for you
    – jfs
    Oct 4, 2015 at 0:02
  • 3
    @TinyGiant: empty titles are trivial to check: [](http://example.com) [](example.com) vs. [non-empty example](http://example.com) non-empty example
    – jfs
    Oct 4, 2015 at 0:05
  • This makes perfect sense, until you remember that the column size for comments in the DB is around 600 characters (the current limit), and it would need to be expanded for this to have any impact.
    – Kevin Brown-Silva
    Oct 8, 2015 at 16:18
  • 2
    @KevinBrown: you've missed the part about splitting comments on the client.
    – jfs
    Oct 8, 2015 at 16:20
  • 5
    Instead of not counting the URLs, I would suggest making them all of the same length. E.g. in Twitter all URLs have the same character count (23). This can be done by e.g. storing URLs separately and only a hash/index in the comment itself.
    – Igor Skochinsky
    Apr 7, 2017 at 9:02
  • @IgorSkochinsky it is one possible way to implement it (essentially, it embeds the URL shortener into SE itself but it can be transparent for the user).
    – jfs
    Apr 7, 2017 at 13:53
  • I agree with you.
    – SarGe
    May 26, 2020 at 13:03

1 Answer 1

Reset to default
1

While we understand your issue about longer lengths for non-English URLs, this request is because the comment field has a hard limit in our database. Increasing the field size has broader implications that we don’t want to introduce.

Improve this answer
8
  • 6
    I think this answer only applies to a very limited part of the question. The OP specifically stated: " if the database limit for comments can't be increased, then [....]". Your answer doesn't acknowledge that.
    – Luuklag
    Mar 25, 2021 at 18:57
  • 1
    @Luuklag This question was written as sort-of a combo feature request, which often isn't a good way to do it, as it substantially muddies the water and makes a resolution of the request much harder, other than just responding to the main point. In other words, it seems like it would be a good idea to have the feature request of automatically breaking up long comments as a separate feature request question, which can then be handled separately. In the case of this question, the title is fairly clear that it's wanting to effectively have longer length comments (from a database POV),
    – Makyen
    Mar 25, 2021 at 20:58
  • with the additional issue of automatically breaking too-long comments into multiple individual comments buried in a paragraph in the middle of the question. Having the request for auto-breaking long comments in a separate question (which is potentially a duplicate) would allow it to be addressed individually. There would probably be responses both as to as to why it's not a good idea as a general capability and why it would be. Someone would probably also write a userscript to do it (e.g. I have one which does it for chat, which I've intended to adapt to comments, but haven't yet done so).
    – Makyen
    Mar 25, 2021 at 20:58
  • 1
    @Makyen yeah you're probably right. I can't blame Anita for not reading the entire post with a finetoothcomb. At the same time I don't think there is much use in having a feature to auto-split comments, as the usefullness is limited to a very small number of comments. And when things start to become as long as they need multiple comments they might be worth a seperate answer on Main sites.
    – Luuklag
    Mar 26, 2021 at 10:02
  • Can you specify what those "broader implications that we don’t want to introduce" are? That might make this a lot more informative.
    – Joachim
    Mar 26, 2021 at 10:49
  • @Makyen: there is a single request ("discourage url shorteners", encourage references that back up corresponding statements in the comments). The rest is just some options how it can be implemented: It doesn't matter how it is implemented as long as it does.
    – jfs
    Mar 26, 2021 at 17:58
  • @jfs No, there's a single goal, with a couple of potential feature requests which attempt to accomplish that goal. Writing it the way you have muddies the water quite a bit and assumes that the people in charge will care enough about your goal to take ownership of the goal and come up with solutions which both accomplish your goal and work within the existing system. Probably a better way to handle something like this is to have a discussion which explores potential solutions to your goal, then one or more concrete feature-request posts which propose the actual solution(s).
    – Makyen
    Mar 26, 2021 at 18:09
  • @Joachim I would be surprised if performance isn't one of those implications. But I'm sure the armchair performance experts reading this have a "solution" for that as well.
    – rene
    Mar 27, 2021 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .