Page MenuHomePhabricator

Allow custom short URL
Closed, DeclinedPublic

Description

User may be able to create an custom short URL. The short URLs can still be disabled by stewards, and no automatic short URL identical to them will be generated.

Technically, we need a new database table to store them (see also T221016#5358449).

To reduce the abuse potential, the followings may be considered (not mandatory):

  1. Creation of custom short URL may be limited to a specific user group (e.g. autoconfirmed user)
  2. There should be a special page to list all newly-created short URL (T228779: Create a special page to list all short URLs)
  3. Creation of custom short URL may be logged, while other short URL creations are still anonymous (this should be clearly explained in the interface)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 25 2019, 10:04 PM

@Bugreporter: Which underlying problem would this solve? For which specific example is the current functionality not sufficient?

Legoktm closed this task as Declined.Jul 25 2019, 10:40 PM
Legoktm added a subscriber: Legoktm.

This was considered during https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener and intentionally not implemented.

Bugreporter added a comment.EditedJul 26 2019, 2:35 PM

This was considered during https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener and intentionally not implemented.

Are there any discussions about it? I can not find a discussion in either the MediaWiki.org page or the task linked to.

@Legoktm I also cannot find any discussion for that.

I do think we can add (though not enable) this function, and than discussion how it can be used.

@Legoktm Do you think it is still inappropriate to do so even if only admins can create custom short URLs and creation of custom short URLs are logged?

I would like to reopen this task and discuss pros and contras

Bugreporter reopened this task as Open.Jan 16 2020, 6:02 PM
Aklapper closed this task as Declined.Jan 16 2020, 8:57 PM
In T242464#5793897, @Aklapper wrote:

Why would anyone want to "reuse" URLs? Cool URIs don't change.

In T242464#5794080, @Ladsgroup wrote:

This is against HTTP standard, a URI should stay consistent and we can't make w.wiki/Foo to something and then to something else later. Not to mention immutability gives us performance gains in DB level like replication, locking and integrity checking.

Bugreporter reopened this task as Open.Jan 16 2020, 9:53 PM

@Aklapper This is a different task than T242464: Feature Request: Expiration date for short links. In this task it's not proposed to make non-persistent short URL.

Der_Keks added a comment.EditedJan 16 2020, 10:17 PM

@Aklapper please step away from this excessive behavior with admin rights. You don't want this, we already noticed that but stop blocking our opinions and ideas without a valid reason!

  • This issue is a different one. It has nothing to do with T242464
  • You didn't care about our question "where it was discussed" so we reopened the Task to discuss it.

To answer your question "For which specific example is the current functionality not sufficient?": For printing shortlinks on flyers, posters, handouts, husiness cards. The underlying problem is that there are guys outside who don't know that HTTP GET is case sensitive. They want a working, easy-to-enter/easy-to-remember URL which works case insensitive. They don't care if you say "they should just enter it twice", they won't enter the URL twice they will break off, say good bye Wikipedia, and then the promotion's ruined. Over, out, for the bin...


So advantages for having custom URLs is

  • One case system
  • Only numbers if you want
  • can be used for acronyms like w.wiki/helloworld which can be remembered much better than w.wiki/N3f4jCV0l
  • figurehead for the project in wikipedia, wikbooks, wikiquote etc...

I like the proposal as described above but I would limit access to create custom URLs to administrators only. This gives the advantage that bickering between two users who want to have the same url is moderated. This would also eliminate the otherwise necessary logging like described above.

@Der_Keks: I mixed up tasks and did not read closely, I'm sorry for that. (And it is technically irrelevant for any actions whether someone has "admin" rights or not.)

Hmm, what does this proposal have to do with Accessibility?

This was considered during https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener and intentionally not implemented.

Are there any discussions about it? I can not find a discussion in either the MediaWiki.org page or the task linked to.

In the IRC meeting (https://www.mediawiki.org/wiki/Talk:Requests_for_comment/URL_shortener#IRC_meeting_2013-09-24) there was some discussion about the importance of making the URLs human readable, and it was decided (through lack of implementation) that it wasn't an important feature. Furthermore, it wasn't in Tim's implementation suggestion, which is what we ended up following.

@Legoktm Do you think it is still inappropriate to do so even if only admins can create custom short URLs and creation of custom short URLs are logged?

I don't think it's worth doing. Adding a user right adds in a new series of bureaucracies that I don't really want to be responsible for. What happens if sysops on different projects want the same short URL since it's a global database? etc. Then someone introduces a "Global custom short URL policy".... :| I'd really like to keep UrlShortener simple and avoid scope screep. Then there's the extra technical work and maintenance.

To answer your question "For which specific example is the current functionality not sufficient?": For printing shortlinks on flyers, posters, handouts, husiness cards. The underlying problem is that there are guys outside who don't know that HTTP GET is case sensitive. They want a working, easy-to-enter/easy-to-remember URL which works case insensitive. They don't care if you say "they should just enter it twice", they won't enter the URL twice they will break off, say good bye Wikipedia, and then the promotion's ruined. Over, out, for the bin...

Case-sensitivity is an entirely separate issue. If we made the URLs case-insensitive, then we'd cut the character set in half, making the URLs even longer. In any case, making URLs easy to remember was not a priority for this project. Making them easy to *transcribe* is.

So advantages for having custom URLs is

  • One case system
  • Only numbers if you want
  • can be used for acronyms like w.wiki/helloworld which can be remembered much better than w.wiki/N3f4jCV0l
  • figurehead for the project in wikipedia, wikbooks, wikiquote etc...

You're probably just better off linking the full URL then.

Bugreporter added a comment.EditedJan 17 2020, 11:50 AM

Then someone introduces a "Global custom short URL policy"

We even does not have a global username policy. Anyone can create a user with almost arbitrary name, and it will be global.

We can still make custom user case sensitive. As long as it is recommended to have short URL in OneSpecificCase or another_one, it will not be a issue in printing or transcribing.

(My idea is all users will be able to create custom URL and creation of them is logged. This is somewhat analogus to external short URL service (everyone can create short URL) and what MediaWiki usually does (creation of new pages and new accounts is logged).)

TheDJ added a subscriber: TheDJ.EditedJan 17 2020, 7:22 PM

I think the point Is not getting across entirely. If someone wants to take over maintenance and spent their free time to maintain the extension for the next couple of years to support the extra overhead of extra functionality, u can do so. But lacking that person, please don’t expect someone else to do this work for u.
There is also no bandwidth nor priority at the foundation to support this for the community.

Bugreporter added a comment.EditedJan 17 2020, 11:05 PM

If nobody is going to work on this, it should be Lowest. Declined means it should not happen even if someone is working on this and maintaining this.

Der_Keks added a comment.EditedJan 18 2020, 7:12 PM

Hmm, what does this proposal have to do with Accessibility?

Oh ahm I think that it affects accessibility (Calling an article via shortlink comfortably (easy to remember, case, etc.))

In T229064#5812138, @Legoktm wrote: In the IRC meeting (https://www.mediawiki.org/wiki/Talk:Requests_for_comment/URL_shortener#IRC_meeting_2013-09-24) there was some discussion about the importance of making the URLs

human readable, and it was decided (through lack of implementation) that it wasn't an important feature. Furthermore, it wasn't in Tim's implementation suggestion, which is what we ended up following.

Oh I found it. But the scope was wmf-urls only. Which was withdrawn later in the chat

<^d> But Elsie is saying it'd be nice to have the short url mean something.
<manybubbles> Elsie: "I think the de-obfuscation is less important since we're limiting it to wmf urls - but still worth doing."
...
<brion> making the short urls look meaningful is tricky… but one could devise some ideas. it's worth considering as an adjunct

Now 6 years are over and the system is in production. For me new usecases have arisen and I hope also for others. Of course I see a problem with interlanguage wikis which want the shorturl w.wiki/ww2 or /nato for example.

Case-sensitivity is an entirely separate issue. If we made the URLs case-insensitive, then we'd cut the character set in half, making the URLs even longer. In any case, making URLs easy to remember was not a priority for this project. Making them easy to *transcribe* is.

Yeah I am aware of the consequences of having case insensitive urls. But I don't see the use case at the moment in this (the current) implementation. Why you should shorten URLs when they have been risen to let's say 6 case sensitive characters?

  • Sending digital via Mail/IRC/Whatsapp doesn't need shorten URLs
  • To write it down for another person manually -> Problems understanding with "I" (i) and "l" (L) for example. Instead of writing down a cryptic URL for my friend I would say "Google for 'Theory of relativity'". That's what I meant with the originally scope (see above); I am sure that the most shortlinks link to Discussion pages in every namespace and in the article namespace of many wikis

Like I said i see new possibilities to use short urls:

  • Printing it on publicity and promotion stuff -> the "i-L"-problem is eliminated but it's still cryptic you need to look between your cup, your keyboard and screen to enter w.wiki/sD$cI which is printed on a cup. But in this case the cup could refer to a not indexed namespace so I cannot say "Google 'Wikipedia <nice-project>'".

So the second use case I see should be currently used mostly. But maybe I forgot an important case.

You're probably just better off linking the full URL then.

I like the idea with the cup... it came just while I wrote this text above. If we make cups for possible newbie-authors for our regular's table (dt.: "Stammtisch") I could now write:

  • "Regular's table Frankfurt \n Come, discuss, collaborate \n <QR-code> \n de.wikipedia.org/wiki/Wikipedia:Frankfurt"

or

  • "Regular's table Frankfurt \n Come, discuss, collaborate \n <QR-code> \n w.wiki/ffm-tisch"

or

  • "Regular's table Frankfurt \n Come, discuss, collaborate \n <QR-code> \n Google for 'Wikipedia Stammtisch Frankfurt'"

I am really sure that only very focussed people which want to know hardly what's behind this will write it down and nobody would search for this term.

I think the point Is not getting across entirely. If someone wants to take over maintenance and spent their free time to maintain the extension for the next couple of years to support the extra overhead of extra functionality, u can do so. But lacking that person, please don’t expect someone else to do this work for u.

You mean that there will be so much requests for that feature in average? At the moment I'm just cleaning behind on dewiki, approving versions and hunting socks. I have no problem to spend some time a day, making a list with requests for human readable urls, and waiting a while for somebody who also claims this url.

Reedy added a subscriber: Reedy.

Hmm, what does this proposal have to do with Accessibility?

Oh ahm I think that it affects accessibility (Calling an article via shortlink comfortably (easy to remember, case, etc.))

You should read the description of that tag

Blocks the accessibility of a wiki (e.g. to blind or partially-sighted people, screen readers, etc.).

https://www.mediawiki.org/wiki/Accessibility_and_usability_cleanup and https://www.mediawiki.org/wiki/Accessibility_guide_for_developers

Not "easy to remember"

Ladsgroup closed this task as Declined.Jan 30 2020, 9:30 PM
Ladsgroup added a subscriber: Ladsgroup.

I deployed the URL shortener whereas most of the work was done by @Legoktm. This request has been made several times before and we declined it explaining why, I'm so tired that I write in full depth again to use it as link in future.

The requested feature was discussed when designing the URL shortener in 2014 but it got rejected. The reasons are performance and scalability. Right now, it stores just a number as the value for the short url (so w.wiki/S is not stored as "S", it's stored as 32). This makes look ups and storage easy so we could easily fit this table in the misc dataabase cluster. Currently, it's not used much because it's not advertised but there are plans to let readers use this (by adding a link in sidebar and apps) the reads and write would sky rocket and it wouldn't work if we store short URL values as string and not integer. Either we had to stop the whole URL shortening feature altogether or get a new cluster which would costs thousands of dollars of donations just for this simple feature, every year.

Let's also look at it in another angle, let's say we changed our mind and we are willing to spend lots of money just to have custom short URLs feature. Since the whole w.wiki is not built with this mentality, it means we need to rewrite everything, it means probably around a month a full developer team (lots and lots of donations money). And stopping building other critical feature or maintenance work. This is unacceptable. If we could do it, we would but it's not just possible. It's not like I wave a wand and you will have this feature.

If you want to fast way to look up your page and you want it to be easy to remember, use bitly or other services. w.wiki is built because you can't link to external URL shorteners in Wikimedia Wikis, having an easy to remember short URL doesn't fit into to problem it tries to solve.

@Ladsgroup thank you for this extended description about the "why". I can understand and accept, the decision. I agree with you that it is not worth to spend 1 month of work into it, there are many other topics which are more useful to invest time into.

It may be helpful if a new service (T232240: New service to shorten wmflabs URLs) will also support creating custom short URL for WMF production URLs.

Bugreporter: Please read again Ladsgroup's previous comment and understand why this is unlikely to happen...