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