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

In T229064#5367266, @Legoktm wrote:

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

@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?

In T229064#5368802, @Bugreporter wrote:

In T229064#5367266, @Legoktm wrote:

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.

In T229064#5793853, @Bugreporter wrote:

@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.

In T229064#5811254, @Der_Keks wrote:

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.

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).)

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.

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.

The last statement is incorrect. "Declined" status also applies "when a report contradicts a particular project's scope (...) and fixing would be barred from approval by the project's Developers/Maintainers".

In T229064#5811461, @Aklapper wrote:

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.

In T229064#5813524, @TheDJ wrote:

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.

In T229064#5814803, @Der_Keks wrote:

In T229064#5811461, @Aklapper wrote:

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 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...