Hey Developers,
We’re considering adding the new Twitter Text linking strategy to the two opt-in developer features we introduced a month ago, so you could simulate how URLs without protocol linking and t.co URLs wrapping will look like on October 10:
- Per-tweet basis: Using the
wrap_links=trueparameter to the POST statuses/update and POST direct_messages/new. - Application basis: Visiting your application settings and configuring this option globally for your application.
Would it be useful if we provided early functionality via these paramaters, or would you prefer that we keep the current behavior of these two opt-in options?
Replies
I think it would be useful. I see a lot of people forgetting to put http:// before their links and the text library doesn't wrap it up to a link.
I completely agree. It would mean that I have to remove certain code from my application that already did this, but really, this change is awesome :-)
BUT
Does this only affect the entities or also change the actual tweet text? After all, with the upcoming change of shortening all URLs with t.co, there'll be a big difference between "twitter.com" (11 chars) and http://t.co/ (21 chars).
This will, in fact, alter tweet text as well. The original "almost a URL and likely meant to be a URL by context & intention" string will be replaced with a "t.co"-based link in the tweet body. If you were building a tweet box with a character counter, you would want to consider any strings that match a URL-like regular expression in twitter-text to be the current maximum length of t.co URLs and present that adjusted count to the user.
Yes it would be useful to have opt-in options prior to the date, probably better if they are separate options from the current wrap_links but either way it'd be useful.
Questions:
The new maths are this:
I'd recommend preventing the submission of a tweet that would be longer than 140 characters on the application level rather than sending it off to Twitter.
Essentially:
Where URLs will soon be defined as both fully qualified URLs as well as these "protocolless" URLs.
My concern as far as my app goes is addressed by your recommendation.
However, my concern for how the Twitter API may behave in the case I outlined remains valid, i.e.: what if some app sends you a tweet with 140 characters length containing shortened, protocol-less URL. What do you do in that case? Reject the tweet or trim it down to 140 after adding the http:// part ? If you trim then where do you trim from, start or end? So my guess is that you'll reject the tweet or may be ignore the protocol-less URL (i.e. not apply the new scheme) ??
What will happen is very similar to what happens today, in that the tweet will be rejected if, after interpretation, it exceeds 140 characters. In this new case, interpreting the link as 140 characters will happen after a "no-protocol URL" is re-evaluated as a t.co link (20 characters at this time).
Cool. That's what I thought.
I'm sending tweets to the timeline from my iPhone app. The tweets arrive at twitter.com as t.co links and are displayed on the timeline as hints. That is, instead of showing up as http://t.co/PJ9hzUI it shows up as exactly maps.google.com/maps?q=-27.348...
When I click on that link, it does not work, just presenting a blank screen.
I have to press the Tweet itself, and it shifts right, where I have to hold my finger on the link, and then it displays the full t.co url, and gives me the option of Opening or Copying the link, or Cancelling.
If I press Open, I am presented with a blank screen, withe the up-to-right arrow in the bottom right. If i then press that option , I am presented with the full expanded link on display, and the options to:
Open in Safari
Mail Link
Repost Link
Read Later
Cancel.
So what's happening? really. For all other shortened links, I just click the link in the timeline and it opens.
Can someone tell me what is happening please?
thanks
Robert
Dear Developers,
We unfortunately won't be able to provide the "URLs without protocol linking" opt-in option prior to date.
These options (per-tweet basis using the
wrap_links=trueparameter, and per-application basis from your app settings) are going to be kept unchanged: wrapping all links regardless of their size (but URL without protocols won't be converted to links before October 10th).Note that in the meantime the new version of twitter-text has been published, in 3 different languages:
Be sure to upgrade if you're using one of these official libraries.
If you're not using twitter-text, you can still check the RegExp we're using there. As an example, here is a simplified version of the twitter-text-java one:
(?: SUBDOMAIN+ DOMAIN ccTLD) | (?: SUBDOMAIN* DOMAIN gTLD) | (?: DOMAIN ccTLD (?=/) )For more details on the t.co URL Wrapper, please check that dedicated documentation page: The t.co URL Wrapper
As usual, if you had any question, please let us know through this thread!
Is a .NET version of the twitter-text library available anywhere?
Hi Arnaud,
It appears the new URL regex's no longer accept URLs immediately prefixed by a period:
This is a pretty common case, and the live site currently extracts these properly. Is this a bug in twitter-text-* or intended behavior going forward?
Cheers,
Adrian ---- -- -
My twitter button on my blog -Alltopstartups.com has stopped counting for about two weeks now. Links shortened via twitter are not being counted. I have reported this about four times already with no response from Twitter.
This is the most horrible, pointless and annoying new feature Twitter has added EVER. If I want to tweet a URL, I want to tweet THAT URL and not some arbitrarily-shortened nonsense t.co garbage. If I want it shortened, I'll bloody shorten it myself.
I want an opt-out!
We need an opt out as well. We tweet information about domain name sales, on twitter it looks fine but off twitter it appears like this:
"The top reported sale of the day is: http://t.co/pHNrDEct - $1,205 - http://t.co/mQJrJeCW"
This makes it entirely useless for us and beyond breaking the domain name so it isn't an actual domain we're at a loss as to what we can do.
Suggestions? Opt-out? Help?
All the data to render those as originally intended is available in the Tweet response object. When rendering off-Twitter, make use of the data and the problem resolves itself. If you encounter a case where an integration is not rendering the t.co as intended, reach out to the site owner and encourage them to make use of the data available in the API.
twitter might die (hopefully not in the nearer future!) at some day. after this day there won't be any chance to click on wrapped hyperlinks included in archived tweets, right?
is there any plan to offer an opt-out of link wrapping or a chance in the near future for users to backup their tweets including their unwrapped hyperlinks (a backup like fb.com/download)?
wrapping urls might be very useful for real-time tracking and phishing prevention but for the long-term public tweets and their hyerplinks should be archivable with unwrapped hyperlinks for the archives of future generations. see also http://joshua.schachter.org/2009/04/on-url-shorteners.html.
As mentioned before, entities are available as part of tweet data responses. Those entities include everything you need to identify the actual URL wrapped by t.co. Wise archivers would include the entire JSON tweet object (for that is a what a tweet "is") in their archives.
It's up to client applications to display URLs in a user-friendly way that is also in tune with the intention of the user. Users who want to use a URL because that's the URL they want to use are honored by clients unwrapping t.co links using tweet entities and displaying to the proper context for the link. User safety is better secured by utilizing t.co for the redirect.
how can i get the Expanded Url from a shortened Url..is there any api supporting this?
....I am...we are...living to day...!
...Sunshine and afterski ...!
...Time willlllllllllllll ....
How do i go behind a picture to see a picture that the real picture