Apostol Apostolov's dashboard

Ping.fm handles badly limited statuses (MySpace, Twitter) if text is longer.

Currently long text is cut abruptly when sent to network with character limit (Twitter, MySpace, many more). This is a very bad way of handling statuses, given so many other networks now allow long (256-1024 chars) messages. It forces the uses to limit themselves to the lowest limit of all his networks when the user should never be forced to limit themselves at all.

I suggest that instead posting verbatim and cutting the remaining text, text longer than the known character limit (140 for Twitter, 160 for Yahoo 360, etc.), the message is rewritten as follows.

1) The message is cut down to the maximum publishable length, as long as all words are complete. If the last word can't be published whole, lower characters until the last word is published whole.
2) Add "..." after last word
3) Add shortened URL (i.e. bit.ly) to the permalink of the message/media.

This way whoever shows interest in the beginning of the message can visit Ping.FM permalink and read the rest of the message/see the media.

Please update the list of countries available for users. I live in Bulgaria, Eastern Europe, a regular EU Member country and I am surprised you don't support our country in your profiles... given that sites like Google feature complete translation in our language of all their services, strikes me surprisingly unwelcome to not even support us.

We wanted to use TweetShrink in our iPhone app but ran into problems with very limited usability of the TweetShrink API. We cannot set target number of characters that we want returned - TweetShrink will shrink the whole message instead only shrinking until target character number is met. Also, if a character number cannot be met because text cannot be shrunk to it, it's good to have a flag that provides an error code. Also, it'd be very good customization feature of the API if the query could include level of shrinkage algorythm (from very conservative and least shrinking to wild and goofy and most shrinking).

Finally, and that's more of a feature request than simple API addition, allow the API query to tell TweetShrink what to do with text if maximum number of characters cannot be met - either to return it's best shot, or use a third-party or first-party feature similar to Twerbose and TweetLonger and ShortText to save text and return a link at the end of the query result that leads to the original, long text via web page.