Getting "The text of your tweet is too long" Error with 140-Character Tweets

fileparade · 2011-11-15T15:24:20.000Z

I have been using the Twitterizer library for .NET to automate posting tweets. This has been working fine for some time.

Recently, I started getting “The text of your tweet is too long” errors. Looking into this, I see my tweets are no longer than 140 characters. Why am I getting this error?

The only related info I could find online was related to changes in the length of the tweet due to converting URLs to t.co URLs. But, looking at the tweets that were posted, it doesn’t not appear there is any conversion from my bit.ly URLs.

Can anyone help me understand what is happening?

episod · 2011-11-15T16:03:57.000Z

For all intents and purposes, all URLs and most things that look like URLs should essentially be considered 20 characters long when composing a tweet. Clients and sites that render t.co links properly make this process mostly transparent – you’ll see a representation of your original bit.ly link in the UI, but underneath it’s still been wrapped with t.co.

fileparade · 2011-11-15T17:11:51.000Z

Thanks for the reply.

Forgive me but the statement that such URLs should “essentially be considered” seems a little vague. Are there some hard and fast rules here that I can follow as a developer that are clearly documented?

Also, does Twitter provide an API for producing t.co URLs? Seems like that would solve the issue.

episod · 2011-11-15T17:18:28.000Z

Everything you’ve ever wanted to know about t.co is in this guide: [node:1163], including [node:1164]. Our link wrapper is meant only to create URLs in relation to tweets (and direct messages), so we don’t provide an atomic URL wrapping function that would create a t.co link outside of the context of a tweet.

orian · 2011-11-16T16:52:09.000Z

I’ve got to say that I find the need to account for t.co wrapping of all links when counting chars to be a real nightmare. For the first time, tweets can now become longer than whatever you send in to Twitter. For the first time, developers have to parse tweets at composition time. For someone like me who is using a language for which there isn’t an official tweet parsing library it means a ton of new work I have to do. I gotta say it really sucks.

fileparade · 2011-11-17T05:37:27.000Z

And I would have to agree. It’s now hit or miss as to whether or not Twitter will accept our tweets!

episod · 2011-11-17T16:11:14.000Z

Long-term, you may see some easing of this burden through possible mock tweet methods or other kinds of API access to a pre-evaluation tweet interpreter.

cryptographite · 2011-12-01T19:35:20.000Z

This is maddening. I’ve started getting this error more and more often, and in the unlikeliest of situations. A user posts something like this (as a real examples):

“etoys.com : Free Shipping on EVERYTHING (up to a $15 value) with your purchase of $69 or more at eToys.com!.. http://dlvr.it/yYsNK”

This is 131 characters. Even if we have to account for t.co (which works out to be the same length as the existing link), there’s no way that this tops 140.

So, what’s the deal? When the text is 138 chars, and the link is less than 20, I can see this potentially happening (though the fact that it happens at all is patently ridiculous), but certainly not when the link is already 20 chars, or the tweet is significantly less than 140.

“Trail Blazers’ Nicolas Batum hopes to return to Portland next week and is … - OregonLive.com (blog) http://frog.ly/bvn #portland #pdx” is 135, and the link is already 18 - so adding two only makes it 137.

“i am #TFB Follow @kaspersky @ccureit @teaminfosec Stay safe online! INTERESTING TWEETERS: t.co/xxekMwrB @2ristic @8rticles… - Thanks!” is only 135, and there’s technically no URL at all. (user was reposting from one account to another, which is why the t.co is already present).

Edit: I think I understand the issue. Every domain, whether it’s a link or not, needs to be counted as if it were a link? I’m sorry, but this behavior is ridiculous.

fileparade · 2011-12-01T21:58:33.000Z

I have to agree this is maddening, and as far as I’m concerned, it’s a real faux pas on the part of Twitter.

This is just about the worst thing Twitter could do. Modify their API so it’s virtually impossible to determine the number of characters that can be included, and then vigorously reject those submissions that exceed it.

This doesn’t seem thought through at all and just seems an all out bad idea. Please review this decision!

kurrik · 2011-12-02T02:08:00.000Z

Every URL needs to be counted as if it were 20 characters, yes. This is done as a safety measure, so I wouldn’t really say “ridiculous”. “Inconvenient”? Sure.

dewaldp · 2011-12-02T13:47:22.000Z

Forcing the developer ecosystem to deal with the inflation of links and domain names is the wrong approach. The right and ecosystem-friendly approach by Twitter would have been to use their internal engineering resources to cope with the t.co inflation above 140 characters, internal in the Twitter system in a way that did not affect users and external developers.

cryptographite · 2011-12-02T18:31:33.000Z

Sorry, no, it’s patently ridiculous. It’s incredibly more than “inconvenient”.

Text is not a URL.
You’re manipulating things after we post which modify the content length. That’s not OUR problem. The text is not over limit, YOU are making it over limit using things which should not count against the posted size in the first place. If I post a string of text, any manipulation you do to it afterward is your responsibility, not that of the user.

This is one of the most backwards, un-friendly API changes I’ve seen from any company.

We have to make huge changes to our system overall to accommodate this change in behavior, so we have to try to figure out whatever your algorithms are for converting links.

It’s really sad that every other service in the world can do things like this transparently, but you have to force it off onto the user.

cryptographite · 2011-12-02T18:32:02.000Z

Exactly my point.

dewaldp · 2011-12-02T19:34:32.000Z

There is a second-best alternative, worse than one having no impact on users and developers, but still magnitudes better than the current situation, namely:

Make it developer policy that we must always use the tweet entities in our display of tweets. Hyperlinks must always have as anchor text the text that the user created, and the href part must contain the assigned t.co URL.
Check the tweet length of the text that the user created, not after the t.co inflation.

The impact on developers is much smaller. It’s a simple loop through the tweet entities, and a preg_replace on the tweet text for each entity (at the time of display, not at the time of tweet creation). There is no impact on the user, because they won’t get rejections on text that they know was not more than 140 characters.

kurrik · 2011-12-02T21:25:55.000Z

The algorithm is described here, including links to libraries which may be of help:
https://dev.twitter.com/blog/twitter-text-library-and-tco-links-wrapping-update

Your feedback is noted, but we’re very unlikely to reverse this change.

fileparade · 2011-12-03T07:00:31.000Z

Why doesn’t Twitter try to design a good API instead?

orian · 2011-12-05T22:03:26.000Z

I agree this implementation is really poor. I posted my suggestions on this thread: https://dev.twitter.com/discussions/2806

In the meantime, I’m not going to invest the time to make my app compatible with these changes (especially since there isn’t a twitter-text library available for my programming language - ActionScript). My users will just have to suffer as the significant time it will take for me to account for this is better spent elsewhere.

tangoroverindia · 2012-07-18T22:53:19.000Z

Can we atleast get some clear guidelines so that we can post correctly? What exactly do I need to do to avoid the “tweet is too long” message.