Hi.
I know this has come up a few times and it's usually the same discussion, but there's now an RFC here, for those interested: https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener.
Thanks to Ryan K. for starting this. :-)
MZMcBride
Fwiw, wi.ki isn't really available. I looked into it years ago, and Kiribati charges excessive amounts for their domains (like 10 grand). Dunno if that's changed.
-Chad On Nov 17, 2012 3:29 PM, "MZMcBride" z@mzmcbride.com wrote:
Hi.
I know this has come up a few times and it's usually the same discussion, but there's now an RFC here, for those interested: https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener.
Thanks to Ryan K. for starting this. :-)
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chad wrote:
Fwiw, wi.ki isn't really available. I looked into it years ago, and Kiribati charges excessive amounts for their domains (like 10 grand). Dunno if that's changed.
I'm not sure I'd say wi.ki is off the table... aside from a domain donation, the Wikimedia Foundation now has an annual budget of somewhere around $30 million, I think. If it wanted to drop a few thousand dollars to buy a shorter domain name, I think it could afford to. The question has become whether doing so is a good idea. :-)
MZMcBride
wi.ki is not available - it's been purchased by a company trying to sell gTLD domains. A couple months ago wi.ki was still available, but not anymore (http://www.wi.ki/)
More than that, they are using Wikipedia's logo stolen from Wikimedia Commons without attribution and infringing on the WMF's trademark.
On Sat, Nov 17, 2012 at 2:45 PM, MZMcBride z@mzmcbride.com wrote:
Chad wrote:
Fwiw, wi.ki isn't really available. I looked into it years ago, and Kiribati charges excessive amounts for their domains (like 10 grand).
Dunno
if that's changed.
I'm not sure I'd say wi.ki is off the table... aside from a domain donation, the Wikimedia Foundation now has an annual budget of somewhere around $30 million, I think. If it wanted to drop a few thousand dollars to buy a shorter domain name, I think it could afford to. The question has become whether doing so is a good idea. :-)
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Nov 17, 2012 at 4:40 PM, Mono monomium@gmail.com wrote:
More than that, they are using Wikipedia's logo stolen from Wikimedia Commons without attribution and infringing on the WMF's trademark.
I've notified our legal team of this infringing use.
Erik
On Nov 18, 2012, at 1:43 AM, Erik Moeller erik@wikimedia.org wrote:
On Sat, Nov 17, 2012 at 4:40 PM, Mono monomium@gmail.com wrote:
More than that, they are using Wikipedia's logo stolen from Wikimedia Commons without attribution and infringing on the WMF's trademark.
I've notified our legal team of this infringing use.
Erik
Also, http://www.wi.ki/ violates the terms of the creative commons license:
https://commons.wikimedia.org/wiki/File:Wikipedia_mini_globe_handheld.jpg https://creativecommons.org/licenses/by-sa/3.0/deed.en
-- Krinkle
2012/11/17 MZMcBride z@mzmcbride.com:
I'm not sure I'd say wi.ki is off the table... aside from a domain donation, the Wikimedia Foundation now has an annual budget of somewhere around $30 million, I think. If it wanted to drop a few thousand dollars to buy a shorter domain name, I think it could afford to. The question has become whether doing so is a good idea. :-)
You must be joking. There is http://ur1.ca/ as a free URL shortener already as a Free service. We should use it and please forget about spending too much money on such "cool" URLs...
Regards, Jürgen.
On Sat, Nov 17, 2012 at 5:30 PM, Juergen Fenn schneeschmelze@googlemail.com wrote:
2012/11/17 MZMcBride z@mzmcbride.com:
I'm not sure I'd say wi.ki is off the table... aside from a domain donation, the Wikimedia Foundation now has an annual budget of somewhere around $30 million, I think. If it wanted to drop a few thousand dollars to buy a shorter domain name, I think it could afford to. The question has become whether doing so is a good idea. :-)
You must be joking. There is http://ur1.ca/ as a free URL shortener already as a Free service. We should use it and please forget about spending too much money on such "cool" URLs...
It's not a matter of "cool urls". Like we don't rely on third parties for other critical services, we shouldn't for a shortener either. URLs shouldn't change and shouldn't die. If that third party resource goes away we'd have a ton of shortened links dead.
Finding a cool, short, url is part of the process of setting up a shortener. Why not suggest some alternatives?
- Ryan
On 18/11/12 04:28, Ryan Lane wrote:
On Sat, Nov 17, 2012 at 5:30 PM, Juergen Fenn schneeschmelze@googlemail.com wrote:
2012/11/17 MZMcBride z@mzmcbride.com:
I'm not sure I'd say wi.ki is off the table... aside from a domain donation, the Wikimedia Foundation now has an annual budget of somewhere around $30 million, I think. If it wanted to drop a few thousand dollars to buy a shorter domain name, I think it could afford to. The question has become whether doing so is a good idea. :-)
You must be joking. There is http://ur1.ca/ as a free URL shortener already as a Free service. We should use it and please forget about spending too much money on such "cool" URLs...
It's not a matter of "cool urls". Like we don't rely on third parties for other critical services, we shouldn't for a shortener either. URLs shouldn't change and shouldn't die. If that third party resource goes away we'd have a ton of shortened links dead.
Finding a cool, short, url is part of the process of setting up a shortener. Why not suggest some alternatives?
- Ryan
Perhaps ask Ward Cunningham if he'd be willing to donate the wiki.org domain to the WMF cause, and have links of the form
wiki.org/<token> ?
to pages on any or all of the WMF-hosted sites?
"wiki.org" is just as memorable as "wi.ki", in my opinion.
Over a billion possible URLs would map quite easily into just six base 35 digits, enough to handle (I think) every revision of every page so far created on all the WMF wikis. That is to say, base 35 using 0-9 plus a-z, without the letter "l" -- easy to type without having to work the shift key up and down, as with so many URL shorteners.
The use of lowecase only makes them easy to read out over the phone and remembered for short periods of a few seconds -- for example,
wiki.org/31z8f2
can be read out as "wiki.org three one zed eight f two". For added goodness, case could be ignored, and "L" interpreted as "1", to further reduce the impact of mis-reading the tokens.
-- Neil
On Sun, Nov 18, 2012 at 1:46 PM, Neil Harris neil@tonal.clara.co.uk wrote:
Perhaps ask Ward Cunningham if he'd be willing to donate the wiki.orgdomain to the WMF cause, and have links of the form
wiki.org/<token> ?
It's a cool idea for a shortener, but a bit rude to assume wiki.org should forever be associated with Wikimedia projects. We're far from the only wiki game in town, and I think it's a little disrespectful to act like it.
Steven
On Sun, 18 Nov 2012 13:46:56 -0800, Neil Harris neil@tonal.clara.co.uk wrote:
Perhaps ask Ward Cunningham if he'd be willing to donate the wiki.org domain to the WMF cause, and have links of the form
wiki.org/<token> ?
to pages on any or all of the WMF-hosted sites?
"wiki.org" is just as memorable as "wi.ki", in my opinion.
Over a billion possible URLs would map quite easily into just six base 35 digits, enough to handle (I think) every revision of every page so far created on all the WMF wikis. That is to say, base 35 using 0-9 plus a-z, without the letter "l" -- easy to type without having to work the shift key up and down, as with so many URL shorteners.
The use of lowecase only makes them easy to read out over the phone and remembered for short periods of a few seconds -- for example,
wiki.org/31z8f2
can be read out as "wiki.org three one zed eight f two". For added goodness, case could be ignored, and "L" interpreted as "1", to further reduce the impact of mis-reading the tokens.
-- Neil
I actually think we should avoid the use of any short domain based on the word 'wiki' for wmf hosted sites.
People still make the mistake thinking that 'wiki' = 'Wikipedia'. We really should not swipe a generic name and perpetuate the misunderstanding with a domain that calls WMF wikis 'wiki'.
My favorite right now is "en.wp.w.mf". Unless you want to spend $100,000. ;) In which case we could revive the age old wish of a .wiki tld, grab some short names for wmf wikis, and make .wiki available for registration of all wiki.
I also like the idea of including a subdomain/path besides the short ID like en.wp.??? so that you can actually understand what site you are going to.
On 19/11/12 10:04, Daniel Friesen wrote:
My favorite right now is "en.wp.w.mf". Unless you want to spend $100,000. ;) In which case we could revive the age old wish of a .wiki tld, grab some short names for wmf wikis, and make .wiki available for registration of all wiki.
I also like the idea of including a subdomain/path besides the short ID like en.wp.??? so that you can actually understand what site you are going to.
There is a tradeoff between providing information and actually managing to shorten the URL.
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.
-- Tim Starling
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
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
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@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
I think the wmf.co and related URLs are our best bet.
On Mon, Nov 19, 2012 at 11:40 AM, Luke Welling lwelling@wikimedia.orgwrote:
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@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
wikitech-l@lists.wikimedia.org