There are some practical reasons for providing site specific domain shortening beyond owning a cool domain hack.
Discouraging the use of third party shorteners has real value. The web getting littered with urls that camouflage their destination, are tied to loss making commercial entities of unpredictable lifetime (eg tr.im), or tied to very well funded commercial entities that choose a ccTLD of unpredictable stability (eg bit.ly) is a bad thing. Providing the option of a short url that achieves whatever benefit was sought without breaking the way the web is supposed to work is a good thing. Email used to be problematic for url sharing, as line breaks inserted at 70 characters would mean the recipient needed to notice that some urls had been chopped and reassemble them. This is probably only true for mailing lists now, as people who deliberately use a plain text only email client in 2012 will experience obtrusive side effects from senders only providing an HTML MIME part regularly. URL chopping will not be their major annoyance. Mailing lists still routinely strip attachments and encodings from mail that they propagate. Mobile generally and twitter specifically are the most often cited justifications now. Aside from the obvious message length limits, cutting and pasting long strings can be hard on a small screen so people are in the short url habit. Twitter is an annoying use case, as even if presented with a short url it currently replaces it with a potentially longer t.co url. If all the project does is reduces the use of third party services that can permanently or transiently fail, can hide links to malware, break search engine rankings and search behaviour, and provide others with analytic insight into potentially sensitive user click throughs it is a good thing. Luke Welling PS my unobtainable cool domain hack of choice would be en.cy (but Cyprus don't do top level subdomains and require local presence) On Mon, Nov 19, 2012 at 5:49 AM, Neil Harris <n...@tonal.clara.co.uk> wrote: > On 19/11/12 02:09, MZMcBride wrote: >> >> Tim Starling wrote: >>> >>> Providing a traditional URL shortener with traditional features would >>> be useful, at least for some people, and would eliminate the need to >>> use third-party URL shorteners internally, which have a commercial >>> focus and unknown lifetime. If there was no integration with MW >>> required, it would only take a couple of hours to set up. >> >> Who's using third-party URL shorteners internally? A lot of services would >> be useful to at least some people (Wikimedians), but the cost of setting >> up >> _and maintaining_ such a service can't be overlooked, in my opinion. Yes, >> it >> would take a few hours to set up a URL shortening service (if that), but >> who's going to be responsible for fixing bugs in it, adding features, and >> doing general maintenance to the service for the indefinite future? There >> are already a number of Wikimedia services that struggle for limited >> resources. Before we add another, we must answer the maintenance question. >> >> MZMcBride >> >> > > If a Wikimedia URL shortening service was to be created, it would make sense > to, at the very least, (a) make the shortened link to real link mappings > part of the standard Mediwiki XML dumps, so that they can be preserved > alongside the content to which they refer, for access by future archivists, > and (b) participate in initiatives such as the Internet Archive's > 301works.org to preserve these links entirely outside the Wikimedia > universe. > > Also, on a separate but related note, has anyone considered creating DOIs > for individual wiki page revisions? > > -- Neil > > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
