I think the wmf.co and related URLs are our best bet.
On Mon, Nov 19, 2012 at 11:40 AM, Luke Welling <[email protected]>wrote: > 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 <[email protected]> > 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 > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
